Close one issue. That's all it took.

One click closed an issue on GitHub. That closed the linked task in our app. Closing the task fired our own "task changed" listener, which pushed the change back to GitHub, which closed the issue again, which fired another webhook, which closed the task again. I had built a machine whose entire job was to bury GitHub's API in its own echo.

It ran fine in testing. Of course it did. Loops need a real round trip to form, and my test never went all the way around the circle. The bug was waiting for production like it had manners.

Both directions worked, and that was the bug

When we wired up two-way sync between GitHub issues and sparQ tasks, the happy path was easy. Close an issue on GitHub, we close the task. Close a task in sparQ, we close the issue. Both directions worked the first time I tried them.

The thing is, "both directions worked" is the bug. Reading activity one way is forgiving. The moment you sync two systems in both directions, you get a failure mode that one-way sync simply cannot have: the loop.

It goes like this. A close comes in from GitHub over a webhook. We close the task. But closing a task is a change, and we have a listener watching for task changes so it can push them back to GitHub. So it pushes. GitHub closes the issue. GitHub fires a webhook telling us the issue closed. We close the task. Which is a change. Which we push. Which closes the issue. You can see where the rest of the afternoon went.

No single step is wrong. Each one is doing exactly its job. Arranged in a circle, they become a feedback loop whose only output is more work for itself.

The fix is boring, and that's the point

Before we apply a change that came from GitHub, we set a flag that says "this one came from a sync, do not bounce it back."

_SYNC_IN_PROGRESS[task.id] = True
try:
    Task.resolve(task.id, resolver_id=None, note="Closed via GitHub")
finally:
    _SYNC_IN_PROGRESS.pop(task.id, None)

Then the listener that pushes changes to GitHub checks the flag first and stays quiet while it's up:

if _SYNC_IN_PROGRESS.get(target.id, False):
    return

That's the whole thing. A dict, a flag, a try/finally. The GitHub change still closes the task, but the push-back is suppressed for that one task while the flag is set, so the circle never closes.

One detail I like: when GitHub closes a task, we resolve it with resolver_id=None. The None isn't laziness. It's the marker that a system did this, not a person, so the activity log can say "closed via GitHub" instead of stamping someone's name on a thing they never touched. The flag stops the loop. The None keeps the history honest.

What it taught me

Two-way sync is not "one-way sync, twice." The second direction hands you a whole category of bug the first one can't have. Once a change can travel in a circle, you need some way to tell "a person did this" apart from "the sync did this," or you end up with a very dedicated little machine for attacking your own API.

It never showed up in a single test. It showed up the first time a real close traveled all the way around the loop. A dict and a flag are the only thing standing between a working sync and a self-inflicted outage.

sparQ is open source (AGPL v3) and self-hostable. The sync lives in pulse/modules/integrations/github/sync.py if you want to read the rest.