Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix feat(feishu): support in-place card content update on button click [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#64828•Fetched 2026-04-12 13:26:31
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
TaoXieSZTaoXieSZ
Participants
TaoXieSZTaoXieSZ
Timeline (top)
cross-referenced ×1

Fix Action

Fix / Workaround

When building a card with buildFeishuCardInteractionContext, allow the caller to embed an updateCard payload in the envelope's uc field. After the button action is processed, maybeUpdateCard calls the Feishu API to patch the original card message to the new state, giving instant visual feedback.

// In card builder:
buildFeishuCardInteractionContext({
  ...
  updateCard: { /* Feishu card element patch */ },
})

PR fix notes

PR #64027: feat(feishu): support in-place card content update on option click

Description (problem / solution / changelog)

Summary

When a card button's interaction envelope carries an uc (update card) payload, the Feishu card-action handler now patches the original card message after the action is processed.

Before: card stays stale after button click
After: card immediately reflects updated content

Changes

  • card-interaction.ts: add optional uc field to envelope context; add isRecord guard in decodeFeishuCardAction validation
  • card-ux-shared.ts: add optional updateCard param to buildFeishuCardInteractionContext, surfaced as uc in the envelope
  • monitor.account.ts: extract message_id from card-action event payload (already declared in type but was not being parsed)
  • card-action.ts: add maybeUpdateCard helper; call it after FEISHU_APPROVAL_CANCEL and before FEISHU_APPROVAL_CONFIRM/quick actions

Usage

Cards built with buildFeishuCardInteractionContext can include an updateCard content. After the user clicks a button, the card is patched to the new state before (for quick actions) or after (for cancel) the command is dispatched, giving instant visual feedback.

AI-Assisted

  • AI-assisted: yes (Claude Sonnet 4.6 via Claude Code)
  • Testing: 605 feishu extension tests pass; live Feishu test TBD

Test plan

  • pnpm test:extension feishu — 605 tests pass
  • Live Feishu test: verify card patches after button click

Review response

  • Greptile P2: resolved — added isRecord guard for uc field in decodeFeishuCardAction (commit 97d45c29)

Closes

Closes #54023 (filed separately as #64828)

Changed files

  • extensions/feishu/src/bot.ts (modified, +8/-0)
  • extensions/feishu/src/card-action.ts (modified, +31/-1)
  • extensions/feishu/src/card-interaction.ts (modified, +5/-0)
  • extensions/feishu/src/card-ux-shared.ts (modified, +3/-0)
  • extensions/feishu/src/monitor.account.ts (modified, +1/-0)
  • extensions/feishu/src/monitor.comment.test.ts (modified, +2/-187)
  • extensions/feishu/src/reply-dispatcher.ts (modified, +61/-16)

Code Example

// In card builder:
buildFeishuCardInteractionContext({
  ...
  updateCard: { /* Feishu card element patch */ },
})
RAW_BUFFERClick to expand / collapse

Problem

When Feishu cards are rendered with interactive buttons (approval confirm/cancel, quick actions, etc.), clicking a button triggers the action but leaves the card in its original visual state. Users see no immediate feedback until the next agent reply arrives — which can take several seconds or longer.

Proposed Solution

When building a card with buildFeishuCardInteractionContext, allow the caller to embed an updateCard payload in the envelope's uc field. After the button action is processed, maybeUpdateCard calls the Feishu API to patch the original card message to the new state, giving instant visual feedback.

Before: card stays stale after button click
After: card immediately reflects the updated content

Usage

// In card builder:
buildFeishuCardInteractionContext({
  ...
  updateCard: { /* Feishu card element patch */ },
})

Related

  • PR #64027 implements the handler-side support
  • Closes #54023

extent analysis

TL;DR

To fix the issue of Feishu cards not updating visually after button clicks, embed an updateCard payload in the envelope's uc field when building the card with buildFeishuCardInteractionContext.

Guidance

  • Review the usage example to understand how to embed the updateCard payload in the buildFeishuCardInteractionContext function.
  • Verify that the updateCard payload is correctly formatted as a Feishu card element patch.
  • Check the related PR #64027 for handler-side support implementation details.
  • Test the updated card rendering after applying the proposed solution to ensure instant visual feedback.

Example

buildFeishuCardInteractionContext({
  // existing properties...
  updateCard: {
    // Feishu card element patch, e.g. updated button state or text
    "title": "Updated Card Title",
    "elements": [
      // updated element properties
    ]
  }
})

Notes

The proposed solution relies on the correct implementation of the maybeUpdateCard function and the Feishu API patch request. Ensure that these components are properly integrated and tested.

Recommendation

Apply the workaround by embedding the updateCard payload in the buildFeishuCardInteractionContext function, as this provides instant visual feedback to users after button clicks.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#cache error#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING