Memgraph Boolean Expression Type Checking Anomaly

Have you ever noticed how sometimes the order of your operands in a query can lead to unexpectedly different results? This is precisely the intriguing behavior we're diving into today concerning Memgraph's handling of boolean expressions. Specifically, we've observed a peculiar discrepancy in how Memgraph treats mixed-type operands within boolean operations like OR and AND. It seems that in certain scenarios, the order in which you present true, false, and integer literals can lead to either a successful query execution or a type mismatch error. This isn't just a minor quirk; it can significantly impact the reliability and predictability of your graph database queries, especially when dealing with dynamic data or complex logical conditions. Let's unpack this phenomenon and understand why it's happening and what it means for your Memgraph usage.

The Curious Case of true OR 1 vs. 1 OR true

We've been investigating a specific behavior within Memgraph (version memgraph/memgraph:latest as of December 7, 2025) when running queries via Docker on WSL2 (Ubuntu 24.04.1 LTS). The core of the issue lies in the type checking of boolean expressions. When you mix boolean literals like true and false with integer literals (e.g., 1), Memgraph's response can be inconsistent depending on the operand order. Consider these examples:

When you execute RETURN true OR 1 AS a;, Memgraph happily returns true. Similarly, RETURN false AND 1 AS a; returns false. This suggests that Memgraph is, in these instances, successfully evaluating the expression despite the mixed types. However, the moment you reverse the operand order, things change dramatically. Executing RETURN 1 OR true AS a; results in a Client received query exception: Invalid types: int and bool for OR. error. The same applies to RETURN 1 AND false AS a;, which also throws an Invalid types: int and bool for AND. error. This stark contrast in behavior, purely based on operand order, is the central point of our discussion. The expected behavior, in an ideal scenario, would be for all such mixed-type operations to fail with a type mismatch error, regardless of the order. This would ensure type safety and prevent unexpected outcomes.

Why the Discrepancy? Unpacking Short-Circuit Evaluation

The most probable explanation for this order-dependent behavior in boolean expressions is the implementation of short-circuit evaluation. This is a common optimization technique used in many programming languages and query engines. For boolean OR, if the left operand evaluates to true, the entire expression is true, and the right operand doesn't even need to be evaluated. Conversely, for boolean AND, if the left operand evaluates to false, the entire expression is false, and the right operand is skipped.

Let's apply this to our Memgraph examples. In RETURN true OR 1 AS a;, the left operand is true. Because it's an OR operation, Memgraph can immediately determine that the result is true without needing to evaluate 1. It effectively short-circuits and returns true. Similarly, for RETURN false AND 1 AS a;, the left operand is false. In an AND operation, this means the entire expression is false, so Memgraph short-circuits and returns false, again without evaluating 1.

Now, consider the reversed cases: RETURN 1 OR true AS a; and RETURN 1 AND false AS a;. Here, the left operand is 1 (an integer). Memgraph attempts to evaluate this first. Since 1 is not a boolean literal, and Memgraph, in this specific context, seems to enforce stricter type checking when the boolean literal is not the first operand, it encounters a type mismatch error between the integer 1 and the boolean true (or false). It fails to proceed with the evaluation, raising the observed exception. This strongly suggests that while Memgraph can sometimes implicitly handle or ignore the type mismatch when the boolean literal appears first and triggers short-circuiting, it does enforce type checking when the integer appears first and requires evaluation of both operands.

This behavior highlights a potential inconsistency in Memgraph's type coercion or evaluation strategy for boolean operators. While short-circuiting is a standard optimization, it shouldn't mask underlying type errors that would otherwise be flagged. The fact that true OR 1 succeeds while 1 OR true fails points to an area where Memgraph's query engine might be exhibiting less predictable behavior than desired for robust application development.

Implications for Developers and Users

This order-dependent type checking in Memgraph's boolean expressions has several important implications for developers and users working with the database. Firstly, it introduces an element of unpredictability. You might write a query that works perfectly fine in one context or with a slight variation in data, only to encounter a type error later when the operand order shifts due to how the query is constructed or how data is processed. This can lead to debugging headaches and unexpected application failures. Relying on implicit type coercion, especially when it's dependent on operand order, is generally considered a fragile practice. It makes your queries less readable and harder to maintain because the behavior isn't immediately obvious from the logical intent.

Secondly, it raises concerns about data integrity and query robustness. If Memgraph is allowing true OR 1 to evaluate successfully, it implies some form of type coercion or implicit conversion is happening. However, the fact that 1 OR true fails suggests that this coercion isn't universally applied or is dependent on specific evaluation paths. This inconsistency can lead to subtle bugs where data that should have been processed differently based on strict type checking is instead processed, potentially leading to incorrect results downstream. For applications that rely on precise logical operations, this kind of ambiguity can be problematic. For instance, in security-sensitive queries or financial calculations, even minor inconsistencies in logical evaluations can have significant consequences.

Moreover, this behavior can obscure the actual intent of the query. When writing true OR 1, a developer might intend for the 1 to be treated as a boolean true (a common coercion in some languages), or they might be unknowingly relying on a short-circuiting behavior that hides a potential type error. If the strict intent was to ensure that only boolean types are used in boolean operations, then both true OR 1 and 1 OR true should raise an error. The current behavior means that developers might inadvertently write queries that are not as type-safe as they believe, leading to potential issues when the data or query patterns change.

Finally, this issue affects how queries are optimized and executed. While short-circuit evaluation is a valuable performance optimization, its interaction with type checking needs to be carefully managed. If Memgraph's query planner or execution engine prioritizes short-circuiting over immediate type validation in certain scenarios, it can lead to these observed anomalies. Understanding this behavior is crucial for writing Memgraph queries that are not only performant but also reliably correct and maintainable in the long run. It underscores the importance of explicit type handling and rigorous testing of logical operations, especially when mixing data types.

Expected vs. Actual Behavior: A Clearer Picture

Let's reiterate the core of the problem by clearly contrasting the expected behavior with the actual behavior observed in Memgraph. Our expectation, rooted in principles of type safety and predictable query execution, is that any boolean operation involving operands of differing types should result in a type mismatch error. This principle ensures that the database enforces strict type constraints, preventing potentially ambiguous or erroneous evaluations.

Expected Behavior:

• Type Safety First: When a boolean expression involves mixed types (e.g., a boolean literal like true or false combined with an integer literal like 1), the query engine should immediately detect this type incompatibility.
• Consistent Error Handling: Regardless of the order of the operands, a type mismatch error should be raised. This means that both true OR 1 and 1 OR true should produce the same error, and similarly for AND operations.
• Predictable Logic: Developers can rely on the fact that if they attempt to mix types, an explicit error will alert them, guiding them towards writing more robust and type-correct queries.

Applying this to the specific queries:

• RETURN true OR 1 AS a; should fail with a type mismatch error.
• RETURN false AND 1 AS a; should fail with a type mismatch error.
• RETURN 1 OR true AS a; should fail with a type mismatch error.
• RETURN 1 AND false AS a; should fail with a type mismatch error.

Actual Behavior:

As reported and observed, Memgraph's actual behavior deviates from this expectation in a way that is dependent on operand order:

• Order-Dependent Success:
  • RETURN true OR 1 AS a; succeeds and returns true.
  • RETURN false AND 1 AS a; succeeds and returns false.
• Order-Dependent Failure:
  • RETURN 1 OR true AS a; fails with Client received query exception: Invalid types: int and bool for OR.
  • RETURN 1 AND false AS a; fails with Client received query exception: Invalid types: int and bool for AND.

This divergence highlights that Memgraph's query engine, when encountering a boolean literal as the left-hand operand in an OR or AND operation, appears to engage in short-circuit evaluation before or instead of enforcing strict type checking for the other operand. This means the potential type error is effectively masked by the optimization. Conversely, when an integer literal appears as the left-hand operand, Memgraph attempts to evaluate it, encounters the type mismatch with the subsequent boolean operand, and correctly raises an error. The key takeaway is that the short-circuiting mechanism for boolean operators seems to be preventing the type error from being raised when the boolean literal is the first operand, leading to inconsistent behavior.

This discrepancy is significant because it means that the success or failure of a query can depend not just on the logical intent but also on the syntactic arrangement of the expression, which is not ideal for a database system that aims for robustness and predictability. It suggests that Memgraph's boolean evaluation logic might need refinement to ensure consistent type checking across all execution paths.

Recommendations and Best Practices

Given the observed order-dependent type checking in Memgraph's boolean expressions, it's crucial for developers to adopt certain practices to ensure query robustness and predictability. The most fundamental recommendation is to avoid mixing data types in boolean expressions altogether. While Memgraph might sometimes appear to handle it gracefully, as seen with true OR 1, this behavior is not reliable and can mask underlying issues. Strict adherence to using only boolean literals (true, false) in boolean operations will prevent these type-related anomalies from occurring.

If you find yourself needing to use a value that represents a boolean state but is stored as an integer (e.g., 0 for false, 1 for true), it is highly recommended to explicitly cast or convert these values to boolean types before using them in boolean expressions. For example, instead of RETURN 1 OR true;, you should aim to transform 1 into true explicitly within your query. The exact mechanism for this might depend on Cypher extensions or specific functions available in Memgraph. However, the principle remains: ensure both operands are of the boolean type before the logical operation is performed. This proactive conversion makes your queries more readable and guarantees that type checking is applied correctly.

Furthermore, it's advisable to test your boolean logic thoroughly, paying close attention to edge cases and operand order. When developing complex queries, especially those involving dynamic data or user-generated conditions, execute all variations of your boolean expressions to confirm consistent behavior. If you encounter unexpected outcomes, revisit the query to ensure type consistency or implement explicit conversions. Writing clear, self-documenting queries is always a best practice, and ensuring type correctness is a significant part of that.

For those managing Memgraph deployments, it's important to be aware of this behavior. While it might not cause issues in all scenarios, understanding its potential impact on applications relying on precise logical operations is key. Consider implementing linting rules or pre-commit checks for your graph queries that flag potential type mismatches in boolean expressions, encouraging developers to adhere to best practices. Community feedback and potential bug reports are also valuable in driving improvements to the database engine.

Ultimately, the goal is to write code that is easy to understand, maintain, and, most importantly, correct. By prioritizing type consistency and explicit conversions in your Memgraph queries, you can mitigate the risks associated with order-dependent type checking and build more reliable graph applications. Always strive for clarity and correctness over perceived convenience that might lead to subtle, hard-to-debug errors.

Conclusion

The observed order-dependent type checking in Memgraph's boolean expressions, where true OR 1 succeeds but 1 OR true fails, is a fascinating anomaly that sheds light on the intricate interplay between query optimization (specifically short-circuit evaluation) and type safety. While short-circuiting is a valuable performance tool, its current implementation in Memgraph seems to mask type errors when the boolean literal precedes the non-boolean operand. This leads to unpredictable behavior and potential pitfalls for developers aiming for robust and reliable graph database applications.

As discussed, the best path forward involves avoiding mixed-type boolean operands and explicitly converting any non-boolean values to their boolean equivalents before performing logical operations. This ensures that Memgraph's type checking mechanisms are consistently applied, leading to predictable outcomes and preventing subtle bugs.

We encourage developers to be mindful of this behavior and to rigorously test their boolean logic. By adhering to best practices for type consistency, you can harness the full power of Memgraph without falling prey to its more enigmatic behaviors.

For further insights into Cypher query language best practices and type handling, you might find the official Neo4j Cypher Manual to be an invaluable resource, as Memgraph's query language is based on Cypher.