stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Log Today recap time concurrently within the foreground deadline #607

New Issue
Closed
opened 2026-08-12 01:19:35 +00:00 by rockachopa · 0 comments
rockachopa commented 2026-08-12 01:19:35 +00:00
Member
Copy Link

Problem

The Today recap time-log endpoint processes up to 20 selected Gitea entries serially. Each upstream request may consume most of the 10-second transport timeout, while foreground dashboard mutations abort after 15 seconds. A normal multi-item recap can therefore report an unknown outcome before all entries are attempted.

User value

Operators can finish a multi-item day recap without manual Gitea reconciliation when individual upstream requests are slow.

Acceptance criteria

  • Process selected entries with bounded concurrency of at most 3.
  • Preserve request order in the returned per-entry outcomes.
  • A slow or failed target does not prevent other selected entries from being attempted.
  • Keep existing logged, retry, and verify idempotency and audit semantics.
  • Five 100ms upstream calls complete inside 350ms in a behavioral test.
  • Focused and full test suites pass.

Evidence / non-duplication

src/main.py currently awaits each gitea_proxy.log_issue_time inside a serial loop. Historical issues #587 and #589 added recap time logging and authorization/auditing; #246 bounded transport-wide traffic. None adds bounded concurrent recap fan-out. Current origin/main is bf2cf37.

## Problem The Today recap time-log endpoint processes up to 20 selected Gitea entries serially. Each upstream request may consume most of the 10-second transport timeout, while foreground dashboard mutations abort after 15 seconds. A normal multi-item recap can therefore report an unknown outcome before all entries are attempted. ## User value Operators can finish a multi-item day recap without manual Gitea reconciliation when individual upstream requests are slow. ## Acceptance criteria - Process selected entries with bounded concurrency of at most 3. - Preserve request order in the returned per-entry outcomes. - A slow or failed target does not prevent other selected entries from being attempted. - Keep existing `logged`, `retry`, and `verify` idempotency and audit semantics. - Five 100ms upstream calls complete inside 350ms in a behavioral test. - Focused and full test suites pass. ## Evidence / non-duplication `src/main.py` currently awaits each `gitea_proxy.log_issue_time` inside a serial loop. Historical issues #587 and #589 added recap time logging and authorization/auditing; #246 bounded transport-wide traffic. None adds bounded concurrent recap fan-out. Current origin/main is `bf2cf37`.
timmy was assigned by rockachopa 2026-08-12 01:19:35 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#607
No description provided.
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?