[github-actions]

Summary

When an index run cannot acquire the database lock within 30 minutes, it previously exited with code 0 (success), causing Container Apps and the workflow to show green even though nothing was actually indexed. This is problematic when users manually trigger re-embeds and watch the results — they see a successful workflow when the index was never actually updated.

Changes

• Modified scripts/rules-chat/index-rules.mjs line 202 to set process.exitCode = 1 when the lock times out (when sp_getapplock returns -1)
• The script now exits with a non-zero code, causing Container Apps execution to end Failed and the workflow to show red
• This ensures failure alerts fire as expected for unintended lock timeouts

Impact

• Visibility: Manual re-embed operations now correctly show as Failed when they can't acquire the lock, making it clear to users watching the results that nothing was indexed
• Monitoring: The hourly job's failure alert will fire for lock timeout cases, but this is expected and correct — the alert is already designed to detect meaningful failures vs expected timeouts during long first-time indexes or re-embeds (as noted in the issue)
• No behavior change: The indexing logic is unchanged; this only affects the exit code

Related Issues

• ♻️ The Rulekeeper - Index from one workflow that starts the Azure job #2800 - Refactored workflows to use Azure job from single workflow
• 🧹 Rules chat index - Low-priority follow-ups from #2758 #2788 - Low-priority follow-ups from Rulekeeper implementation

Closes #2809

Generated by Issue Triage for issue #2809 · ● 63.9K · ◷