Background
Round 14a (PR #108) added data-show-scroll-button attribute observability to fix the React-render vs WebKit-event-loop race that rounds 11-13 had partially mitigated.
This issue tracks the deferred Round 14b work: seeding deterministic conversation data.
Why this is now low-priority (was originally planned alongside 14a)
After Round 14a landed, the WebKit timing-race symptom is gone. The remaining argument for 14b is about deterministic data shape, not flake elimination:
- The test (
messaging-scroll.spec.ts:266 T007-T008) currently uses "whichever conversation is first by Most Recent." That conversation could have 5 messages or 500.
- For thin conversations, the test silently skips the assertion (
if (scrollInfo.distanceFromBottom > 500) is false). It "passes" but verifies nothing.
- For thick conversations, the test asserts correctly.
The test isn't broken without 14b — it's just non-deterministic about whether the assertion actually runs. With 14a's observability fix, when the assertion DOES run, it's reliable.
What 14b would do
Add a test.beforeAll(...) hook in messaging-scroll.spec.ts that seeds 30 messages into the test conversation via the Supabase admin client. Pattern mirrors tests/e2e/auth.setup.ts. 30 messages × 80-120px per message = 2400-3600px of scroll height, guaranteeing the assertion always enters the if branch.
Math
- Test scrolls
scrollHeight - clientHeight - 600 pixels up
- Then asserts button visible IF
distanceFromBottom > 500
- For the assertion to run reliably,
scrollHeight - clientHeight needs to exceed 600 + 500 = 1100px
- At 80-120px per message: ~14 messages minimum, 30 messages for comfort
Acceptance
Related
🤖 Created as follow-up after round 14a validation in PR #108
Background
Round 14a (PR #108) added
data-show-scroll-buttonattribute observability to fix the React-render vs WebKit-event-loop race that rounds 11-13 had partially mitigated.This issue tracks the deferred Round 14b work: seeding deterministic conversation data.
Why this is now low-priority (was originally planned alongside 14a)
After Round 14a landed, the WebKit timing-race symptom is gone. The remaining argument for 14b is about deterministic data shape, not flake elimination:
messaging-scroll.spec.ts:266T007-T008) currently uses "whichever conversation is first by Most Recent." That conversation could have 5 messages or 500.if (scrollInfo.distanceFromBottom > 500)is false). It "passes" but verifies nothing.The test isn't broken without 14b — it's just non-deterministic about whether the assertion actually runs. With 14a's observability fix, when the assertion DOES run, it's reliable.
What 14b would do
Add a
test.beforeAll(...)hook inmessaging-scroll.spec.tsthat seeds 30 messages into the test conversation via the Supabase admin client. Pattern mirrorstests/e2e/auth.setup.ts. 30 messages × 80-120px per message = 2400-3600px of scroll height, guaranteeing the assertion always enters theifbranch.Math
scrollHeight - clientHeight - 600pixels updistanceFromBottom > 500scrollHeight - clientHeightneeds to exceed600 + 500 = 1100pxAcceptance
beforeAllhook inmessaging-scroll.spec.tsseeds 30 messages into the test conversationafterAll(consistent with other messaging specs)Related
auth.setup.tspattern for admin-client seeding🤖 Created as follow-up after round 14a validation in PR #108