🐛🧑‍💻 - Issue assignment loses organization lookup diagnostics behind opaque retryable provider.unavailable #849

Is there an existing issue for this?

• I have searched the existing issues.

Related opaque-diagnostic reports #718 (commit size reconciliation) and #646 (Bugbot finding reconciliation) concern different stages. Exact searches for the organization-member lookup message found no matching report. This report does not assume their underlying cause is the same.

Which actions are affected?

Issue

Which platforms are affected?

Linux

Description

One ordinary Domus issue-lifecycle attempt reports that it cannot list organization members or assign the configured one assignee, then fails after other external effects with only generic provider.unavailable/retry-when-available guidance. The public diagnostic does not retain a safe provider operation, HTTP/error classification, affected stage or explanation of which remaining work actually needs retry. A genuinely transient provider failure may be valid; the defect reported here is the lost actionable cause/recovery context, not a claim that GitHub was definitely unavailable or that permission rejection occurred.

Consumer: vypdev/domus#17 . Exact failed run: https://github.com/vypdev/domus/actions/runs/41337490802 . This is independent of the successful pre-branch SDD clarification run 41337316893; do not conflate the two. A later authoritative issue read shows efraespada assigned; another ordinary event may have completed assignment, so this report does not claim that the issue is currently unassigned or that all attempts failed. The issue remains usable and the consumer continues answering its normal SDD gate. No Action rerun, configuration edit or credential-scope expansion was performed.

Expected: preserve current bounded/redacted failure behavior while reporting that organization-member lookup/assignment failed, its safe provider operation/status/category if known, whether retry is appropriate, and the exact retained/remaining effects. Authorization/unavailable/malformed-source failures must not be indistinguishable to operators. Do not log tokens, response bodies, private member lists or organization secrets. A partial-effect retry must be safe and avoid duplicating successful project/type/configuration effects.

Actual: CheckPermissions is skipped because the issue is not newly opened; AssignMemberToIssueUseCase says one assignee is needed, immediately logs Unable to list organization members and Unable to assign members, and continues. Native type update, existing Project linkage/priority and configuration storage complete. Final summary reports 6 results, 5 steps, 1 error. The final message identifies no assignment/provider-operation context and merely says the provider was temporarily unavailable, retryable Yes, reference fa5bee5c-715b-47dc-97f7-e531e463c718. The logs expose no HTTP status or underlying error, so root cause cannot responsibly be inferred from this evidence.

Reproducing the issue

1. Inspect the exact unmodified released-SDK consumer run above and the retained stage order/timestamps below. It is an observed external failure, not a claimed deterministic fault-injection reproduction.
2. In an SDK-owned isolated regression fixture, make organization-member lookup fail separately as unavailable, denied, malformed response and unexpected provider error. Configure ordinary issue assignment to require one member.
3. Assert the failure remains redacted but preserves safe operation/stage/category and truthful retryability; no fake/empty member list or assignment success is produced.
4. Assert successful independent type/Project/configuration effects remain identified and a safe retry does not duplicate them. Explicitly distinguish a real transient failure from persistent authorization/configuration conditions without expanding credentials.
5. Include an already-assigned issue control and a known eligible-member successful control. These are suggested regressions; they have not been executed in the consumer.

copilot Version

vypdev/copilot@v3, immutable downloaded revision 3e7ceea. Consumer default source 8ee7e1a15e91c91b6204ca97e8808c3207dee008. This reports the observed release, not an unexecuted current-development fix.

Relevant Log Output

2026-11-01T18:39:54.8126147Z Executing AssignMemberToIssueUseCase.
2026-11-01T18:39:54.8128895Z #17 needs 1 assignees.
2026-11-01T18:39:54.8262339Z Unable to list organization members.
2026-11-01T18:39:54.8276509Z Unable to assign members.
2026-11-01T18:39:56.5485553Z Successfully updated issue type to Feature
2026-11-01T18:40:05.1895917Z Content is already linked to project [public diagnostic identifiers omitted here].
2026-11-01T18:40:26.6606421Z Field Priority is already set to P2. No update needed.
2026-11-01T18:40:30.9498631Z Publishing result: 6 result(s), 5 step(s), 1 error(s).
2026-11-01T18:40:31.5152034Z Configuration stored. Finishing.
2026-11-01T18:40:31.5306807Z Impact: The provider was temporarily unavailable.
Error code: provider.unavailable
Action: Retry when the provider is available.
Retained state: Existing persisted state and completed external effects were preserved.
Retryable: Yes
Reference: fa5bee5c-715b-47dc-97f7-e531e463c718

Additional context and comments

The current organization-member lookup HTTP status, provider response and underlying exception are unavailable in the emitted diagnostics. Do not infer missing organization permission, an actual network outage or a model failure from the generic classification. This consumer report changes no Copilot code, installed resources, workflow configuration or credentials; the upstream team owns the fix. Branches remain Action-owned. The consumer will continue the admitted product work without waiting for this diagnostic improvement.