Add refreshHandler feature.

[dlongley]

No description provided.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 81.91882% with 49 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.97%. Comparing base (01dbcd9) to head (d3de252).

Files with missing lines	Patch %	Lines
lib/storage/ConfigStorage.js	65.27%	25 Missing ⚠️
lib/storage/ConfigRefresher.js	86.28%	24 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #44      +/-   ##
==========================================
+ Coverage   83.15%   83.97%   +0.81%     
==========================================
  Files          12       13       +1     
  Lines        1538     1772     +234     
==========================================
+ Hits         1279     1488     +209     
- Misses        259      284      +25     

Files with missing lines	Coverage Δ
lib/config.js	100.00% <100.00%> (ø)
lib/index.js	73.00% <100.00%> (+0.97%)	⬆️
lib/storage/ConfigRefresher.js	86.28% <86.28%> (ø)
lib/storage/ConfigStorage.js	79.08% <65.27%> (+1.96%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 01dbcd9...d3de252. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mattcollier]

In addition to this implementation, you may want to consider how this might work in the context of a cron job sort of approach or possibly a webhook. A job based approach will better support deployments where applications are idle/suspended or scaled to zero.

https://cloud.google.com/run/docs/execute/jobs-on-schedule

I also wonder what the best way to surface unresolved refresh failures given the critical nature of the task.

[dlongley]

In addition to this implementation, you may want to consider how this might work in the context of a cron job sort of approach or possibly a webhook. A job based approach will better support deployments where applications are idle/suspended or scaled to zero.

https://cloud.google.com/run/docs/execute/jobs-on-schedule

These are good considerations.

The design is such that the integrated scheduler could be, in the future, disabled and augmented (without too much effort, I think) with a webhook / cron job style driver if desired. However, this alternate approach doesn't also come with downsides, including introducing additional dependencies on those driving systems and then monitors for those -- as well as authorization and DoS considerations on the interfaces that might be used to trigger the behavior. There would also be additional infrastructure setup, etc. Perhaps with time both approaches might become available (with the drawback of additional maintenance).

I also wonder what the best way to surface unresolved refresh failures given the critical nature of the task.

Monitoring logs and / or using the webhook mechanism to obtain metrics (e.g., number of stale service object configs -- including those that are not "refresh enabled") instead of driving the refresh mechanism itself might be options for getting information on areas that are in need of manual intervention.