spindle writes down where a branch pointed after it handles a push, and reads that back as the old commit for the next push on the same branch. the knot's own feed hands us the old commit in the event, so the note only matters where it does not. what was wrong: - spindle built the note for every repo before it started serving, and gave up on the whole process when one knot was down. on production that is 183 knots - it took an old saved position as proof the note was built. it was not built, so the first update after a fallback was refused, not run - it asked whether a branch was new only after reading the current branches, so a branch made in that gap looked like it already existed and the changed files came out wrong - it wrote the note before making the run. if it died in between, the push was counted as handled and never ran - after wiping a note it did not build it again what it does now: - nothing is built at startup, so no knot can keep spindle from starting - an op that reports no old commit falls back to the note; if there is no note either, this is the first push we have seen for that branch and it runs with no old commit, then we write the new one down - a push whose changed files we could not work out is no longer excluded by a paths filter. the filter still skips when we know the files and none match, and every other trigger keeps its old behaviour - the note is written after the run exists, so a push can run twice but is not skipped - the repo row is written before we listen to its knot, so a ref op for a brand new repo is not dropped as someone else's the cost is the first push per branch after a note is lost: it runs without an old commit, so its changed-file list is empty and a paths filter cannot skip it. Signed-off-by: dawn <dawn@tangled.org>