landing-demo: re-enable Sync_Propagates_To_Peer_Tab e2e test

[adnaan]

Background

The landing-demo example (PR #93) ships with a Sync() controller method that the framework's docs say will be auto-dispatched to peer connections in the same session group after every action. The README and the docs landing page promise: "open this page in another tab and watch them sync."

The chromedp e2e test that exercises that promise — TestLandingDemoE2E/Sync_Propagates_To_Peer_Tab in landing-demo/landing_demo_test.go — is currently t.Skip'd because reliable two-tab coverage didn't fit in PR #93's scope.

What was tried

Two test shapes, both unreliable:

1. Open peer tab, increment in original, assert peer reflects. Original-tab increment timed out at 5s waiting for body.innerText.includes('Count: 1').
2. Open peer tab, increment in peer, assert original reflects. Peer-side increment landed within 5s; original-tab Sync round-trip didn't arrive within 10s.

Both setups used chromedp.NewContext(parentCtx) to spawn the peer tab in the same browser allocator. In a real browser, two tabs sharing the same browser process share cookies and therefore land in the same LiveTemplate session group. Whether that's actually true for chromedp's child-context targets is the open question.

Suspected causes (need confirmation)

• Session-cookie propagation across chromedp targets. A child context shares the browser allocator but each target has its own request/response surface; the session cookie set on tab 1's first response might not be sent on tab 2's HTTP request, putting them in different session groups.
• WS upgrade context. Even if cookies do propagate, the WebSocket upgrade may carry a different cookie jar than the initial HTTP request in chromedp's target model.
• Test harness timing. The e2etest.WaitFor polling loop may interact poorly with the WS receive timing on a second connection — though 10s should be ample for any reasonable async dispatch.

Manual verification (works)

Loading https://lt-landing-demo.fly.dev/ in two tabs of the same real browser and clicking +1 in either updates both counters. The cross-tab claim on the landing page is correct as a feature; this issue is purely about CI coverage.

Acceptance criteria

• TestLandingDemoE2E/Sync_Propagates_To_Peer_Tab runs (no t.Skip) and reliably asserts a peer-tab increment shows up in the observer tab within a few seconds.
• The fix doesn't paper over a real product bug — if the underlying cause turns out to be a missing cookie pass-through in lvt's testing helpers, that fix lands in lvt first.
• A short comment in the test explains the cookie/session-group setup so the test's invariants are auditable.

Implementation notes

Things to try when picking this up:

• Inspect cookies via network.GetAllCookies or chromedp.Cookies after each tab's initial load; verify they're identical.
• Inspect server logs from the test server (landing-demo writes INFO Created new session group) — count distinct group_ids per test run.
• Consider chromedp.NewContext(parentCtx, chromedp.WithTargetID(...)) patterns or sharing an explicit chromedp.NewBrowser between two contexts.
• If lvt's e2etest helpers don't expose a "spawn a peer tab in the same session" primitive, that primitive might belong in lvt/testing so other examples (the multi-user-sync pattern in examples/patterns/realtime/) can reuse it.

Related

• PR: feat(landing-demo): minimal LiveTemplate counter for docs landing page #93
• Skipped test: landing-demo/landing_demo_test.go (search for t.Skip)
• Framework docs on Sync: livetemplate/livetemplate docs/references/server-actions.md ("Tab 2, Tab 3 receive Sync() dispatch")