test: pernot's wait budget was exactly its notification interval - #57
Merged
Conversation
My own regression, from the rewrite two commits ago. That change swapped `sleep 3` for `ftClientWait 2`, which is the right shape - wait for the event instead of guessing a duration - but ftClientWait's budget is 100 x 0.02s = 2s, and the subscription's timeInterval was 2. The second notification is therefore due at t=2.0s, exactly when the wait gives up. So the test raced its own helper. It lost on corDB (585/586 in tonight's run) and won on mongoc, and it won all three valgrind runs I verified it with - because under valgrind the budget is multiplied by 5, to 10s, and the race disappears. I verified the new test under the condition that hides the defect and not under the one that shows it. timeInterval=1 puts the two notifications at t=0 and t=1, inside the 2s budget on either backend, and leaves the point of the rewrite intact: the subscription is deleted before anything asserts that nothing more arrives. Verified mongoc 1/1, corDB 5/5, valgrind 3/3.
kzangeli
added a commit
that referenced
this pull request
Sep 3, 2026
The pushdown builds one positive per-instance predicate and negates the
whole thing for != and !~=. The positive carries a type check inside it,
so negating it turns "wrong type" into "matches" - which § 7.2.3.3 says
is right for one operator and wrong for the other:
!= "if the data type of the target value and the data type of the
Query Term value are different, then they shall be considered
UNEQUAL" -> mismatch MATCHES
!~= "if the target value data type is different than String then it
shall be considered as NOT MATCHING"
So q=a.b.c!~=alp returned the entities whose a.b.c is 3 and 7. A number is
not "a value that does not match /alp/"; it is a value the operator cannot
be applied to.
For a pattern the string check is therefore asserted POSITIVELY, outside
the negation, and only the regex is negated. != keeps the guard inside,
where the spec wants it.
corNgsild#9 fixes the mirror-image bug in the in-broker matcher, which had
the other rule: every type guard there answered plain false - right for
!~= and wrong for !=. Each backend implemented exactly one of the two.
query_q_negation_type_rules.test pins both directions, and needs nothing
to be an oracle: no REQUIRE_DB, so the harness runs it against both
backends, and they evaluate `q` in completely different places. It holds
string targets where the query term is a number AND numeric targets where
it is a string, so neither backend can pass by implementing one rule.
636/636 mongoc, 585/586 corDB (subscription_pernot, unrelated - #57).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
My own regression, from #54 earlier today.
That PR swapped
sleep 3forftClientWait 2— the right shape, waiting for the event instead of guessing a duration. ButftClientWait's budget is100 × 0.02s = 2s, and the subscription'stimeIntervalwas 2. The second notification is due at t≈2.0s, exactly when the wait gives up.So the test raced its own helper:
It lost on corDB (585/586 in tonight's run) and won on mongoc — and it won all three valgrind runs I verified #54 with, because under valgrind the budget is multiplied by 5, to 10s, and the race disappears. I verified the new test under the condition that hides the defect and not under the one that shows it.
timeInterval=1puts the two notifications at t≈0 and t≈1, inside the 2s budget on either backend, and leaves the point of #54 intact: the subscription is deleted before anything asserts that nothing more arrives.The reason is recorded in the test header, since the next person to see a slow pernot test will reach for a bigger interval, which is the change that breaks it.
Verified: mongoc 1/1, corDB 5/5, valgrind 3/3.