Skip to content

fix(agent): propagate custom-agent request cancellation to database operations #2329

Description

@DeliciousBuding

Summary

Refs #2256 (E-P2-3). The production custom-agent handlers pass the request context, but all six database calls in the CRUD service use the unbound shared GORM handle. Cancellation/deadlines therefore do not reach database/sql on this path. The lock-wait/connection-pool impact must be reproduced against isolated PostgreSQL before claiming an improvement.

Scope / Files / File Ownership

One writer on an isolated worktree. Allowed files:

  • hub-server/internal/service/agent/agent_custom.go
  • hub-server/internal/service/agent/agent_custom_context_test.go
  • hub-server/tests/integration/custom_agent_context_test.go

Cover create/list/update/delete, including the ownership-read-to-write boundary. Do not bulk-change unrelated service signatures, background task lifetimes, or middleware semantics.

Interfaces / Invariants

No API or service signature change. Bind each request-scoped database operation to its supplied context. Preserve ownership/not-found rules, narrow-update fields, structured output, and normal uncanceled CRUD behavior. A canceled operation must not become a late mutation.

Acceptance

  • Reproduce old behavior with real PostgreSQL lock waits in disposable local containers, without live application data.
  • L0 behavior checks cover canceled CRUD and cancellation after the ownership read; assert persisted data, not just a WithContext call.
  • L1 drives the real HTTP handler/service/repository path and proves a deadline or disconnected client stops the blocked query and releases the single-connection pool while the blocking lock remains held.
  • Focused unit/integration tests, applicable race/static checks, and required CI gates pass. Report environment, deadline, elapsed result, and evidence level without claiming production frequency or throughput.

Negative Constraints / Dependencies

No production or existing development service restart/configuration change; no network/ACL/DNS, credentials, real model calls, dependency upgrades, or unrelated WIP edits. Reuse the existing PostgreSQL integration harness and deterministic wait utilities. Other candidates in #2256 remain separately tracked; this does not close the whole performance issue.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions