1. Incomplete fix — same bug exists in the post-join filter loop (Medium severity)

  The post-join filter wrapping at line 5041 runs inside a loop (lines 4311-5046). For a multi-table join like:

  SELECT ... FROM A
  INNER JOIN B ON ... WHERE pred_referencing_B
  INNER JOIN C ON ... WHERE pred_referencing_C

  If parallel filter is disabled and both joins have postJoinWhereClause, iteration 1 wraps master in a FilteredRecordCursorFactory at line 5041, and iteration 2 tries to wrap it again
  — triggering the same assertion. The PR only fixes the const-filter-on-top-of-post-join-filter case but not the post-join-on-top-of-post-join case.

  Similarly, generateFilter0() at line 3290 can wrap the result of generateJoins() in yet another FilteredRecordCursorFactory if there's an outer WHERE clause and parallel filter is
  unavailable.

  Recommendation: Apply the same instanceof FilteredRecordCursorFactory check at line 5041, or — better — extract the combine-filters logic into a helper method and use it at all three
  sites.

  2. Exception safety gap between halfClose() and new factory creation (Low severity)

  existingFiltered.halfClose();                    // line 5110 - cursor freed
  // ... allocations happen here ...
  filter = new AndFunctionFactory().newInstance(    // line 5117 - if this threw...
      0, andArgs, argPositions, configuration, executionContext
  );
  master = new FilteredRecordCursorFactory(base, filter);  // line 5120

  After halfClose(), base and existingFilter are orphaned — no factory owns them. If the code between lines 5110-5120 threw, both would leak. Currently AndFunctionFactory.newInstance()
  cannot throw in practice, but the method signature declares throws SqlException. If the implementation ever changes, this becomes a real leak.

  Recommendation: Extract base and filter first, build the combined filter, and only then call halfClose() — or wrap the section in a try/catch that re-closes base and existingFilter on
   failure.

  3. halfClose() doesn't fully follow the lifecycle pattern (Nitpick)

  The existing halfClose() call sites in SqlCodeGenerator follow a consistent pattern with supportsFilterStealing():
  if (factory.supportsFilterStealing()) {
      filter = factory.getFilter();
      base = factory.getBaseFactory();
      factory.halfClose();
      ...
  }

  The PR doesn't add supportsFilterStealing() to FilteredRecordCursorFactory and instead uses instanceof. This works but is inconsistent with the existing pattern. The instanceof check
  is arguably clearer here since this is a specific code path, not the generic filter-stealing mechanism.

  4. Direct instantiation of AndFunctionFactory (Minor style concern)

  filter = new AndFunctionFactory().newInstance(
      0, andArgs, argPositions, configuration, executionContext
  );

  This allocates a new AndFunctionFactory instance just to call newInstance(). While cheap, QuestDB's codebase generally avoids unnecessary allocations. Consider whether the
  functionParser pipeline should be used instead, or at minimum make the factory a static constant.

  Test Coverage

  - The new test testJoinInnerPostJoinAndConstFilter reproduces the exact reported scenario and verifies both no-crash and correct results. Good.
  - Uses assertQueryNoLeakCheck — consistent with the rest of JoinTest.java (all 132 assertions use this variant), so this is fine by convention.

  Missing test coverage:
  - No test for the multi-join nesting scenario (issue #1 above)
  - No test verifying the query plan shows a single combined Filter node rather than nested filters
  - No test with NOW() != NOW() or other non-trivial const expressions to exercise edge cases in the AndFunctionFactory constant-folding paths

  Summary

  ┌─────────────────────────────────────────────────────────────────────┬──────────┐
  │                               Finding                               │ Severity │
  ├─────────────────────────────────────────────────────────────────────┼──────────┤
  │ Same nesting bug exists in the post-join filter loop (line 5041)    │ Medium   │
  ├─────────────────────────────────────────────────────────────────────┼──────────┤
  │ Exception safety gap after halfClose()                              │ Low      │
  ├─────────────────────────────────────────────────────────────────────┼──────────┤
  │ Missing supportsFilterStealing() override (uses instanceof instead) │ Nitpick  │
  ├─────────────────────────────────────────────────────────────────────┼──────────┤
  │ Unnecessary AndFunctionFactory allocation                           │ Nitpick  │
  ├─────────────────────────────────────────────────────────────────────┼──────────┤
  │ Missing tests for multi-join nesting                                │ Medium   │
  └─────────────────────────────────────────────────────────────────────┴──────────┘

  The fix is correct and well-explained for the reported issue. The main concern is that it's a partial fix — the same root problem (nesting FilteredRecordCursorFactory) can be
  triggered via at least one other code path (successive post-join filters in multi-table joins). I'd recommend extracting the combine-and-wrap logic into a helper and applying it at
  all new FilteredRecordCursorFactory(master, ...) sites to make the fix comprehensive.