Skip to content

Read reward label from config instead of a crashing HTTP fetch#152

Draft
wkatir wants to merge 1 commit into
knowall-ai:mainfrom
wkatir:claude/issue-150-config-label-20260714-1631
Draft

Read reward label from config instead of a crashing HTTP fetch#152
wkatir wants to merge 1 commit into
knowall-ai:mainfrom
wkatir:claude/issue-150-config-label-20260714-1631

Conversation

@wkatir

@wkatir wkatir commented Jul 14, 2026

Copy link
Copy Markdown

Description

Replaces the reward-name label mechanism. The label is now read from configuration (LNBITS_POINTS_LABEL) instead of an HTTP fetch to a separate backend at startup. This removes the crash class in #150 at its root, deletes a hardcoded auth token, and supersedes the try/catch band-aid in #151.

Type of Change

  • Bug fix

Related Issues

Fixes #150. Supersedes #151.

Changes Made

Problem

teamsBot.ts fetched a cosmetic label via getRewardName() in an unguarded async IIFE. Any failure (backend down, port conflict) became an unhandled rejection that crashed the bot on Node >= 15. fetchRewardsName.ts also shipped a hardcoded token ('your-secret-token').

Root Cause

A cosmetic label was treated as a runtime network dependency. The label already exists as configuration (LNBITS_POINTS_LABEL), so the fetch was both crash-prone and redundant. sendZapCommand even read REACT_APP_LNBITS_POINTS_LABEL, which never reaches the bot process - it was always undefined.

Fix

  • Delete src/services/fetchRewardsName.ts (removes the fetch and the hardcoded token).
  • Read the label from process.env.LNBITS_POINTS_LABEL in teamsBot.ts and the three commands; fix the wrong REACT_APP_ var name in sendZapCommand.
  • Propagate LNBITS_POINTS_LABEL to the bot via scripts/writeEnv.js.
  • Fail loud at startup if the label is unset (no silent default).

Notes

  • Existing local envs: LNBITS_POINTS_LABEL is only appended to env/.env.local on provision; existing envs must re-provision or add it manually.
  • Behavior change: the label is now static config, so renaming it at runtime via the tab's RewardsNameSetting no longer affects the bot (that path was already failing).

Screenshots (if applicable)

Not applicable - backend change (config and bot startup), no visual surface.

Test plan for QA

  1. With LNBITS_POINTS_LABEL set, start the bot - it starts and cards show the label.
  2. Stop the tab backend / cause the old fetch condition - the bot no longer crashes.
  3. Unset LNBITS_POINTS_LABEL - the bot fails at startup with a clear message.

Checklist

  • Self-review done
  • Tested locally (bot starts, label renders, no crash on backend failure)
  • No new type errors in touched files

🤖 Generated with Claude Code

teamsBot.ts fetched a cosmetic label via getRewardName() in an unguarded
async IIFE; any failure was an unhandled rejection that crashed the bot
(knowall-ai#150). fetchRewardsName.ts also shipped a hardcoded auth token.

The label already exists as configuration, so read it from
LNBITS_POINTS_LABEL instead of over HTTP: delete fetchRewardsName.ts, read
process.env.LNBITS_POINTS_LABEL in the bot and the three commands, fix the
wrong REACT_APP_ var name in sendZapCommand, propagate the var via
writeEnv.js, and fail loud at startup if it is unset. Supersedes knowall-ai#151.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Bot process crashes if fetching the reward name fails

1 participant