Screen captures of the Stripe integration page depend on whether the console's Stripe reads finished before the capture #263

New Issue

2026-10-24T06:52:45Z

cgalo5758 commented

2026-10-24 06:52:45 +00:00

What a contributor runs into

make screens first restores the application database from the demo snapshot (test/reset-app-db.sh), then captures every screen in test/e2e/screens/manifest.go from the running console, operator-integration-stripe (/operator/integrations/stripe) among them. That page renders two stored records: the Stripe account's public details (instance.StripePublicDetails) and the result of the environment check (instance.StripeEnvironmentCheck). The demo seed writes neither, so the snapshot carries neither. The console writes both from Temporal workflows that it starts in the background once its process connects to Temporal (startStripeWork in cmd/start.go), and those workflows read the test stack's Stripe test account. Nothing in make screens waits for those reads or keeps them from landing.

The capture therefore shows one of two pages:

When no read has written its record since the reset, the Public details section says "Not read yet." and the Environment check section says "Not checked yet."
When the reads finish between the reset and the capture, the page shows the account's public business name, statement descriptor and icon, what members are shown because of them, and "Last checked . N verified, M stale." with the time of that run. The page is several rows longer.

The accepted baseline holds one of the two, so a run that captures the other reports the page as changed although no code changed. The member Plans and Add-ons pages show billing facts read from the same public-details record (loadBillingFacts in internal/server/billing_facts.go), so their captures can change the same way when the account's names differ from the deployment's name.

#120 is the same symptom from another cause: cells that count from today.

Why it costs

Every reviewer of changes.txt has to open the Stripe page's diff to tell this from a real change, and a baseline accepted in the second state carries one Stripe account's public details and a run's timestamp, so the next contributor's run differs from it.

Where

test/e2e/screens/screens_test.go

Done when

Two make screens runs with no code change between them capture the Stripe integration page, and the member pages that show billing facts, identically, whether or not the console's Stripe reads ran in between. For example, the harness writes neutral public-details and environment-check records just before it captures the pages that read them, or it masks the regions that carry account details and times.

### What a contributor runs into `make screens` first restores the application database from the demo snapshot (`test/reset-app-db.sh`), then captures every screen in `test/e2e/screens/manifest.go` from the running console, `operator-integration-stripe` (`/operator/integrations/stripe`) among them. That page renders two stored records: the Stripe account's public details (`instance.StripePublicDetails`) and the result of the environment check (`instance.StripeEnvironmentCheck`). The demo seed writes neither, so the snapshot carries neither. The console writes both from Temporal workflows that it starts in the background once its process connects to Temporal (`startStripeWork` in `cmd/start.go`), and those workflows read the test stack's Stripe test account. Nothing in `make screens` waits for those reads or keeps them from landing. The capture therefore shows one of two pages: - When no read has written its record since the reset, the Public details section says "Not read yet." and the Environment check section says "Not checked yet." - When the reads finish between the reset and the capture, the page shows the account's public business name, statement descriptor and icon, what members are shown because of them, and "Last checked <time>. N verified, M stale." with the time of that run. The page is several rows longer. The accepted baseline holds one of the two, so a run that captures the other reports the page as changed although no code changed. The member Plans and Add-ons pages show billing facts read from the same public-details record (`loadBillingFacts` in `internal/server/billing_facts.go`), so their captures can change the same way when the account's names differ from the deployment's name. #120 is the same symptom from another cause: cells that count from today. ### Why it costs Every reviewer of `changes.txt` has to open the Stripe page's diff to tell this from a real change, and a baseline accepted in the second state carries one Stripe account's public details and a run's timestamp, so the next contributor's run differs from it. ### Where `test/e2e/screens/screens_test.go` ### Done when Two `make screens` runs with no code change between them capture the Stripe integration page, and the member pages that show billing facts, identically, whether or not the console's Stripe reads ran in between. For example, the harness writes neutral public-details and environment-check records just before it captures the pages that read them, or it masks the regions that carry account details and times.

cgalo5758 added the

kind

debt

area/testing labels 2026-10-24 06:52:45 +00:00

cgalo5758 referenced this issue

2026-10-26 20:58:24 +00:00

Screen captures print the pinned times in the time zone the console process runs in, so a capture from another zone differs from the baseline #274

Sign in to join this conversation.