memoize: add user feedback and configurable timeout for flock

[iav]

Summary

• Add user feedback when memoize cache lock is held by another process
• Add configurable timeout via MEMOIZE_FLOCK_MAX_WAIT environment variable
• Prevent builds from hanging indefinitely due to stale Docker containers

Problem

When a build is interrupted (e.g., via Ctrl+C or system crash), Docker containers may continue running and hold flock locks on memoize cache files in cache/memoize/. Subsequent builds would hang indefinitely at the "artifact [ kernel :: kernel() ]" stage without any feedback to the user.

Solution

Instead of blocking indefinitely on flock, this change:

1. First tries non-blocking flock -n - acquires immediately if available
2. If lock is busy, informs the user with actionable message
3. Waits with periodic status messages (every 10s by default)
4. Optionally times out after configurable duration
5. Suggests checking for stale containers: docker ps -a | grep armbian

New Configuration Variables

Variable	Default	Description
MEMOIZE_FLOCK_WAIT_INTERVAL	10	Seconds between status messages while waiting
MEMOIZE_FLOCK_MAX_WAIT	0	Maximum wait time in seconds (0 = infinite, for backward compatibility)

Test plan

• Build with no other processes running - should work as before
• Start a build, interrupt it, start another - should show waiting message
• Set MEMOIZE_FLOCK_MAX_WAIT=30 and test timeout behavior
• Verify Ctrl+C works during lock wait

🤖 Generated with Claude Code

[coderabbitai]

📝 Walkthrough

Walkthrough

Modifies the memoization cache file locking mechanism in a single script to replace immediate blocking locks with non-blocking, timed locks featuring configurable retry intervals and maximum wait durations, with periodic status alerts during the waiting period.

Changes

Cohort / File(s)	Summary
Memoization Locking Enhancement lib/functions/general/memoize-cached.sh	Changed from blocking flock to non-blocking flock with retry loop and timeout logic. Added MEMOIZE_FLOCK_WAIT_INTERVAL (default 10s) and MEMOIZE_FLOCK_MAX_WAIT (default 0/infinite) configuration variables. Lock acquisition now emits progress alerts while waiting, failure alerts on timeout, and success alerts with total wait time.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A lock that waits with patience true,
No blocking here—we'll try anew!
With timed retries and friendly cheer,
The memoize cache holds files dear.
Progress whispers as we stand,
Till the lock is in our hand! 🔓

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding user feedback and configurable timeout for the flock mechanism in memoization, which matches the core objective of improving lock handling behavior.
Docstring Coverage	✅ Passed	Docstring coverage is 90.91% which is sufficient. The required threshold is 80.00%.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Docstrings were successfully generated.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[iav]

@CodeRabbit review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Note

Docstrings generation - SUCCESS
Generated docstrings for this pull request at #9263

[rpardini]

While this is nice addition... I'd also like to understand how "When a build is interrupted..., Docker containers may continue running and hold flock locks on memoize cache" happens, and maybe handle it too (add a cleanup handler or such...)?

[iav]

Docker containers may continue running and hold flock locks on memoize cache" happens, and maybe handle it too (add a cleanup handler or such...)?

I encounter this quite rarely, and it happens during multiple manual starts and manual interruptions of the build process. I decided to investigate the situation after my Armbian build suddenly and strangely froze twice within a week. I spent almost an hour trying to figure out what was going on. It was working just a moment ago, and now it gets to a certain point and just freezes, WTF!!! And I can't figure out how to fix it!

However, I don't think something like this could happen anywhere on runners. That is, I believe this situation could only arise with human intervention, and therefore, warning that person about what exactly happened is quite sufficient. Another reason not to automate the cleanup is that I don't know what else could cause such a blockage, so I don't want to break something I have no idea about.

[rpardini]

Ok, this doesn't hurt, and unless MEMOIZE_FLOCK_MAX_WAIT is set, doesn't change anything.

Later, we could investigate why the hang further (probably on the remote call to obtain some version, we could call the memoized function with timeout ...) and maybe in this same spot add a cleanup handler (equivalent to using a bash trap).

[github-actions]

✅ This PR has been reviewed and approved — all set for merge!

[iav]

If it turns out that long blockages are caused by something other than manual build interruptions, then this could be investigated.