Francy51/Neon-Desk
2
0
Fork 0
Code Issues 22 Pull Requests Actions Packages Projects Releases Wiki Activity

Add browser-level regression coverage for filing sync notification aggregation #13

New Issue
Open
opened 2026-03-14 23:32:50 +00:00 by Francy51 · 0 comments
Francy51 commented 2026-03-14 23:32:50 +00:00
Owner
Copy Link

Summary

Issue #5 shipped the queue dedupe and aggregated filing-sync notification surface, but the browser-level notification UI is still only covered indirectly by unit tests and API-level tests.

Why this follow-up exists

The current coverage proves:

  • same-ticker sync_filings requests reuse one in-flight task
  • different tickers still queue independently
  • filing-sync notification entries aggregate correctly and ignore detail-only churn in signatures

What is still missing is one browser-level regression that asserts the user-facing notification center behavior:

  • one filing-sync card in the popover while multiple filing sync tasks are active
  • one stable filing-sync toast during concurrent sync activity

Acceptance Criteria

  • Add a Playwright or equivalent browser test that opens the notification center during concurrent filing sync activity.
  • Assert that the popover shows one Filing sync card rather than one card per underlying task.
  • If toast assertions are practical in the existing harness, assert that only one filing-sync toast is visible while the batch is active.
  • Keep the coverage focused on the aggregated presentation contract, not task-detail internals.
## Summary Issue #5 shipped the queue dedupe and aggregated filing-sync notification surface, but the browser-level notification UI is still only covered indirectly by unit tests and API-level tests. ## Why this follow-up exists The current coverage proves: - same-ticker `sync_filings` requests reuse one in-flight task - different tickers still queue independently - filing-sync notification entries aggregate correctly and ignore detail-only churn in signatures What is still missing is one browser-level regression that asserts the user-facing notification center behavior: - one filing-sync card in the popover while multiple filing sync tasks are active - one stable filing-sync toast during concurrent sync activity ## Acceptance Criteria - Add a Playwright or equivalent browser test that opens the notification center during concurrent filing sync activity. - Assert that the popover shows one `Filing sync` card rather than one card per underlying task. - If toast assertions are practical in the existing harness, assert that only one filing-sync toast is visible while the batch is active. - Keep the coverage focused on the aggregated presentation contract, not task-detail internals.
Francy51 added the P3 label 2026-03-14 23:32:50 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0
Critical priority
 P1
High priority
 P2
Medium priority
 P3
Low priority
No Label P3
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
coolify_deployment Francy51
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Francy51/Neon-Desk#13
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?