WPILOGWriter: stop logging gracefully when disk is full to prevent robot loop overruns

[jasondaming]

Summary

Fixes #259

When log storage fills up, synchronous flush() calls in putTable() can block the main robot loop, causing erratic mechanism behavior mid-match (e.g. mechanisms barely responding, commands not executing). This was observed in competition when a USB drive filled up and write errors caused the logger's queue to back up and stall the 20ms robot loop.

• At startup, reset any stale alerts from a prior run, then check free space:
  • < 50 MB: raise a persistent kError Alert and abort logging entirely
  • < 1 GB: raise a persistent kWarning Alert but continue logging
• Every ~10 seconds during operation (putTable()), recheck free space with the same thresholds; on < 50 MB, close the log and set isOpen = false so the existing guard short-circuits all future calls without blocking on I/O
• Clear lowSpaceAlert in the periodic check if space rises back above 1 GB
• Guard end() against calling log.close() if the log was already closed by the disk-full path
• Add :::warning admonition to existing-projects.md and vscode-welcome.md documenting the thresholds and advising teams to clear logs regularly

Test plan

• Build passes (./gradlew :akit:compileJava)
• Spotless passes (./gradlew spotlessCheck)
• Tested locally via publishToMavenLocal and consumed in a robot project running in simulation
• Verified warning Alert fires when free space is below 1 GB at startup
• Verified error Alert fires and logging stops cleanly when free space is below 50 MB
• Verified no NPE in end() when logging was stopped early by the disk-full path

🤖 Generated with Claude Code

[katzuv]

Shouldn't this be handled at the WPILOGWriter level and not in AdvantageKit?

[jasondaming]

WPILOGWriter isn’t a WPILib class — it’s an AdvantageKit class. So if your point is that this should be handled in WPILOGWriter instead of in higher-level logging code, I agree, and that’s what this change does.

If you mean WPILOGWriter itself should be moved into WPILib, I don’t think that makes sense here.

Let me know if I’m misunderstanding your comment.

[katzuv]

Sorry, I misunderstood. I thought AdvantageKit utilizes WPILib's logging capabilities. Is that not the case? I guess maybe not, as AdvantageKit was created before WPILib had logging.

[blaze-developer]

AdvantageKit does utilize WPILib's logging. WPILogWriter is the class in AdvantageKit that handles writing periodic tables to WPILOG files

If you are curious, consider reading the source code of that class or some other parts of AdvantageKit for a better understanding of how things are structured. That way you'll be more informed with your contributions and suggestions.

[katzuv]

Thanks, what I meant to say in general is that -- can this feature be added to WPILib's side, perhaps in DataLogWriter? Which seems like AdvantageKit is using.

[jasondaming]

DataLogWriter is not the proper place for this kind of check. It is a basic call and any policy decisions should be handled by the higher level library.

For WPILib we use DataLogManager and take a different approach of deleting old log file until there is enough space. I think that is an equally valid solution to this problem it is just a matter of taste. If AKit wanted to go that direction instead we could.