chatops-lark: track cloud-image async workflow runs with explicit request id

[wuhuizuo]

Background

/cloud-image query currently triggers a GitHub Actions workflow and then tries to find the corresponding workflow run by heuristic matching.

Current matching signals are roughly:

• workflow run id must be greater than the latest known run id before dispatch
• event must be workflow_dispatch
• ref must match
• created_at must be close to dispatch time
• display title must match query-image-tag <repo>:<tag>

This is good enough for many cases, but it is not a strong 1:1 correlation between a chat command and a workflow run.

Problem

When multiple users query the same image repo and tag at nearly the same time, we may associate the wrong workflow run with the wrong chat command.

That can lead to:

• replying in the correct Lark thread with the wrong workflow result
• mixing up the final async follow-up message between two near-simultaneous requests
• making future debugging harder because we do not have an explicit request correlation id

The Lark reply target itself is bound correctly by messageID, but the GitHub Actions run selection is still heuristic.

Short-term impact

This is acceptable for now, but it should be tracked because the risk becomes more visible when:

• the same image tag is queried repeatedly
• multiple users trigger the command within a short time window
• the workflow queue is busy or delayed

Suggested direction

Introduce an explicit request correlation id for /cloud-image workflow dispatch.

For example:

• generate a request id in chatops-lark for each command execution
• pass that request id into the workflow dispatch inputs
• expose the request id in workflow run metadata, artifact content, or another stable output
• match workflow runs and async replies by request id instead of only by timing/title heuristics

Optionally later:

• persist pending async query state so replies can survive process restart/pod restart

Acceptance criteria

• two near-simultaneous /cloud-image query requests for the same repo and tag can be unambiguously correlated to their own workflow runs
• async final replies are sent back to the correct original Lark command thread
• correlation does not depend on run title or dispatch timing alone