Repository navigation
test: assert exact query counts in upcoming_events_for_user specs - #3095
Merged
Merged
Conversation
Both regression specs allowed up to two extra queries at four workshops than at one. That slack leaves room for a constant added query, the shape a preload falling back to a non-batched load takes. Measured on both paths: 6 queries at one workshop, 6 at four, so exact equality holds. The chapter-workshops spec also read host outside the counted block, so removing that preload kept both counts equal and left the guard green. It now counts the host reads too, which is how the invitations spec already behaves.
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
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.
Closes #3094.
Both query-count regression specs for
upcoming_events_for_usernow assert exact equality, instead of allowing two extra queries at four workshops than at one. Measured on both paths: 6 queries at one workshop, 6 at four. The slack would hide a constant added query, which is the shape a preload falling back to a non-batched load takes.The chapter-workshops spec had a second hole: it read
hostafter the counted block closed, so deletingpreload(workshop_host: :sponsor)fromchapter_workshops_forleft both counts equal and the example green. It now counts the host reads, which is what the invitations spec already does.Review notes
load_user_events_and_count_host_queriesnow covers the load, the host reads, and the host assertion inside the measured window. The count is 6 either way..upcoming_eventsspec uses the same relative shape.Measured counts and review findings
Measured on this branch, both paths, before and after the change:
Guard check, by deleting one preload at a time and running the spec file:
preload(workshop_host: :sponsor)fromchapter_workshops_for: the chapter example now fails (it passed before this change).preload(workshop: { workshop_host: :sponsor })fromaccepted_workshops_for: the invitations example fails, as it did before.A four-persona review pass (correctness, standards, testing, adversarial) plus an independent validator produced one blocker, fixed here: the chapter example's host reads sat outside the counted window. Two P3 notes were left open deliberately:
count_queriesreports totals only, so a failure does not name the new SQL; and no absolute cap exists, so a uniformly added query passes both sides equally. The validator agreed with those dispositions.