Repository navigation
test(persistence): require every timestamped record to declare whether it is read by time - #1029
Conversation
…r it is read by time Every mapped ICreatedRecord must now appear in exactly one of ChronologicalListTypes and NotReadByTimeTypes in BusinessRecordModelTests. A new timestamped record omitted from both lists fails, which closes the #819 census gap where an omitted chronological contribution stayed green. Closes #1024
|
Review of record: Codex Reviewed PR #1029 at P2 | CONFIRMED | The new guard silently excludes owned Concrete failure scenario: add Evidence:
Make this case fail closed by including owned timestamped entities in the declaration check, or explicitly rejecting them if the persistence policy does not support them. If owned records are deliberately outside this slice, narrow the documented guarantee and explicitly record the remaining gap instead of claiming universal coverage. This is a guard-coverage and documentation defect, not a current product defect. No product defect introduced by this PR was found. Verification results Every run targeted
M2's totals include one extra passing assertion proving the model registration and paged The subject set comes from Exclusion reasons checked All 14 classifications agree with current reads. No newly misclassified time-paged screen or list was found.
The documentation correctly admits that declarations can be false and that review must assess their reasons. Its unsupported claim is the coverage of every mapped Nits: none. All throwaway source changes were restored. The final clean-tree run passed 3/3; see final-clean.log. Verdict: request changes for one confirmed P2 guard/documentation gap; no product defect found. |
… declaration guard Astra round 1 on #1029: an owned ICreatedRecord mapped with OwnsMany to its own table skipped the declaration check. BusinessRecordModel configures no timestamps or Sequence for owned types, so the guard now rejects them outright instead of asking for a declaration.
|
Astra round 1, P2 (owned The fix rejects owned types rather than including them.
Docs changed in the same commit, at exactly this strength. The 819 record's "Migration and enforcement" section and the AGENTS.md #819 paragraph now say owned timestamped types are rejected outright. The existing limit stays stated: a declaration is not checked for truth. Test only, no call graph change. This round found no product defect. |
|
Review of record: Codex Round-two review of PR #1029 at No new P0–P3 findings. The round-one P2 is CONFIRMED FIXED at The original failure scenario was an undeclared
The other three tests pass, including the independent assertion proving the owned mapping, both timestamp properties, the separate table, and successful paged-query SQL generation. That assertion also confirms No product defect was found. This remains a test-and-documentation change with no production behavior change. Policy and current-model check The worker's explanation is accurate. The real model contains five owned mappings, all for The rejection tests interface assignability, not property names. A synthetic owned value with an ordinary Reachable edge cases
Each keyless/view probe separately asserts its actual key and table/view metadata and compiles a paged query through Npgsql. These are reachable EF mappings, and neither keylessness nor view mapping escapes discovery through The remaining boundary is explicit: this guard classifies Nits: none. The new code follows #985, and targeted compilation produced no style violations. Verification used only Verdict: approve the round-two fix; the prior P2 is resolved, with no new finding or product defect. |
Closes #1024
test only, no call graph change
What changes
BusinessRecordModelTestsnow requires every mappedICreatedRecordto appear in exactly one of two lists:ChronologicalListTypes(existing, 12 types);NotReadByTimeTypes(new, 14 types, each with a one-line reason).The new test fails when a timestamped record is in neither list, in both, or when a listed type is not a mapped timestamped record. The existing
Only_chronological_lists_have_a_unique_generated_sequencealready fails when the chronological list and the module contributions disagree. Together, a new timestamped record can no longer skip the chronology decision silently.The guard does not check that a declaration is true. A time-paged record declared in
NotReadByTimeTypesstays green, and review of its reason is the only check. The 819 decision record and the AGENTS.md #819 paragraph state exactly this.The set was measured on
d6dbd47dby running the guard with an emptyNotReadByTimeTypes: 14 undeclared plus 12 chronological, 26 timestamped records.Mutation table
M2 is the #970 probe: a mapped
TimePagedProbeRecord : IMutableRecordwith a realIEntityTypeConfiguration, declared nowhere. "main" meansorigin/main's test file over the same tree.Expenseremoved fromFinanceBusinessRecordsonly (the issue's row)Only_chronological_lists...Only_chronological_lists...TimePagedProbeRecordExpenseremoved from the contribution andChronologicalListTypesExpenseFlockrow deleted fromNotReadByTimeTypesFlockExpenseadded toNotReadByTimeTypestooAuditEvent(not timestamped) added toNotReadByTimeTypesExpenseremoved fromChronologicalListTypesonly, contribution keptM1 was already red on
main, so the issue's own proof row was not discriminating. M2 and M3 are the gap, and they flip from green to red.The harness that ran M0 to M6 (M7 was run by hand) is below.
1024-mutations.sh
Test counts
d6dbd47d--list-testsBusinessRecordModelTestsThe full integration suite was not run locally; CI runs it.
Deslop
pstack:deslopran over the branch diff and removed nothing: the diff has no comments, casts or defensive code.Reasonis deliberately not read by the test; it exists for reviewers.