Skip to content

feat: handle migration_blocker / migration_warning categories (v2026-02-01)#2234

Closed
jeffredodd wants to merge 1 commit into
upgrade/api-2026-02-01-basefrom
upgrade/api-2026-02-01/migration-blockers
Closed

feat: handle migration_blocker / migration_warning categories (v2026-02-01)#2234
jeffredodd wants to merge 1 commit into
upgrade/api-2026-02-01-basefrom
upgrade/api-2026-02-01/migration-blockers

Conversation

@jeffredodd

Copy link
Copy Markdown
Contributor

Summary

🔴 Sub-PR off #2233 (the v2026-02-01 base bump).

v2026-02-01 introduces migration_blocker and migration_warning blocker categories. This PR captures the decision to NOT extend the resolvable-blocker whitelist for these — the existing <GenericBlocker> fallback at both render sites handles unknown types gracefully and disables submit, which is the correct behavior for informational (non-partner-resolvable) blockers.

Changes

  • src/shared/constants.ts: documents the decision inline on PAYROLL_RESOLVABLE_SUBMISSION_BLOCKER_TYPES. No runtime change.
  • e2e/tests/payroll/06-migration-blocker-rendering.spec.ts (new): scaffolds an E2E assertion that GenericBlocker renders + submit is disabled for unknown blocker types. Currently test.skip — needs a Demo company provisioned in a mid-migration state to actually exercise. Tracked alongside SDK-999.

Revisit triggers

Open the whitelist back up if SDK-999 testing reveals:

  • A migration sub-type is partner-resolvable (e.g. has a "click to acknowledge" affordance)
  • Generic copy is confusing in real UX testing — would warrant a dedicated MigrationBlockerBanner component

References

Test plan

  • Confirm GenericBlocker fallback path triggers when blockerType is unknown
  • Wire up a Demo migration scenario and un-skip 06-migration-blocker-rendering.spec.ts
  • Sanity-check that submit is disabled when migration_blocker is present

🤖 Generated with Claude Code

…02-01)

🔴 Sub-PR off #2233. Adds the decision and verification scaffold for the
new migration_blocker / migration_warning categories introduced in
@gusto/embedded-api-v-2026-02-01.

Decision: do NOT extend PAYROLL_RESOLVABLE_SUBMISSION_BLOCKER_TYPES.
The existing GenericBlocker fallback at PayrollOverviewPresentation.tsx:668
and PreviewPresentation.tsx:140 already renders unknown blocker types
gracefully and disables submit. The new categories are informational
(not partner-resolvable), so the fallback is correct. Decision is
documented inline on the whitelist for future maintainers.

E2E coverage: 06-migration-blocker-rendering.spec.ts asserts the
GenericBlocker fallback path renders + disables submit. Currently
test.skip pending a Demo scenario provisioning a company in mid-migration
state — tracked alongside SDK-999.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jeffredodd jeffredodd force-pushed the upgrade/api-2026-02-01/migration-blockers branch from a5d2e91 to 7c777d8 Compare June 23, 2026 16:14
@jeffredodd

Copy link
Copy Markdown
Contributor Author

Closing: this PR's analysis was based on a conflation between two different blocker concepts. The new migration_blocker / migration_warning categories from v2026-02-01 live on partner_managed_companies/migration_readiness — an endpoint with no SDK consumers in src/. They never flow through PAYROLL_RESOLVABLE_SUBMISSION_BLOCKER_TYPES or the GenericBlocker render path. The typecheck CI step verifies the regenerated Zod schemas parse the new categories. Documented in the base PR #2233.

@jeffredodd jeffredodd closed this Jun 23, 2026
@jeffredodd jeffredodd deleted the upgrade/api-2026-02-01/migration-blockers branch June 24, 2026 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant