fixit automation closed #154 despite push failure — same fix(#146) never-pushed pattern as #156 #157

Closed
opened 2026-07-26 01:02:07 +00:00 by Mark · 1 comment
Owner

Finding

The findit/fixit automation for issue #154 (second attempt to fix #146) ran to completion and closed both #146 and #154, but the fix commit b4a2bde was never pushed to origin/main.

Local main is at b4a2bde (1 commit ahead). Origin/main is at d5f3efd — does NOT include the fix.

This is the same pattern documented in #156 for the #155 findit attempt: the automation's finalize_after_kilo function calls close_issue regardless of whether the push to origin succeeded.

Root cause

As documented in the forgejo skill (hermes-config):

Push failure does not block issue close — finalize_after_kilo calls close_issue regardless of push success

The close_issue call should be gated on push_ok in finalize_after_kilo. The current behavior is: gates pass → close regardless of push outcome.

Impact

  • Anyone deploying from origin/main will NOT have the Settings controls fix
  • Both #154 and #146 show as "CLOSED" but the fix is unreachable
  • Developers cloning fresh from origin get the broken Settings page

Events

  • fixit card: t_3fd495e5 (completed)
  • fix commit: b4a2bde (local only, never pushed)
  • issues closed: #146 (underlying), #154 (findit tracking issue)
  • prior instance: #156 (same pattern for #155 findit attempt)

Suggested fix

In the automation pipeline, gate close_issue on push success. If safe_push fails, the issue should remain open with a note about push failure rather than being closed as "fixed."


Kanban card: t_7bd49718

## Finding The findit/fixit automation for issue #154 (second attempt to fix #146) ran to completion and closed both #146 and #154, but the fix commit `b4a2bde` was **never pushed to origin/main**. Local main is at `b4a2bde` (1 commit ahead). Origin/main is at `d5f3efd` — does NOT include the fix. This is the same pattern documented in #156 for the #155 findit attempt: the automation's `finalize_after_kilo` function calls `close_issue` regardless of whether the push to origin succeeded. ## Root cause As documented in the forgejo skill (hermes-config): > Push failure does not block issue close — `finalize_after_kilo` calls `close_issue` regardless of push success The `close_issue` call should be gated on `push_ok` in `finalize_after_kilo`. The current behavior is: gates pass → close regardless of push outcome. ## Impact - Anyone deploying from origin/main will NOT have the Settings controls fix - Both #154 and #146 show as "CLOSED" but the fix is unreachable - Developers cloning fresh from origin get the broken Settings page ## Events - fixit card: t_3fd495e5 (completed) - fix commit: b4a2bde (local only, never pushed) - issues closed: #146 (underlying), #154 (findit tracking issue) - prior instance: #156 (same pattern for #155 findit attempt) ## Suggested fix In the automation pipeline, gate `close_issue` on push success. If `safe_push` fails, the issue should remain open with a note about push failure rather than being closed as "fixed." --- *Kanban card: t_7bd49718*
Author
Owner

Commit b4a2bde (fix(#146): restore Settings interactions) is now on origin/main. This issue was filed against a transient push failure; the fix has landed. Closing as resolved.

Commit b4a2bde (`fix(#146): restore Settings interactions`) is now on origin/main. This issue was filed against a transient push failure; the fix has landed. Closing as resolved.
Mark closed this issue 2026-07-26 14:43:33 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/kimi_agent_kin_app_sync#157
No description provided.