feat(prerender): support retry and retryDelay

[Hebilicious]

🔗 Linked issue

Resolves #1469

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

The prerender by default will fail if a page fails to render. This PR changes the default behaviour to 3 attempts before failure.
This also adds 2 configuration options nitro.options.prerender.tries and nitro.options.prerender.retryDelay to change the behaviour. tries can be set toInifinityif someones wants the pre-render to try endlessly.

For the default values, I've arbitrarily chose 2 retries and a 250ms retry delay.

Additional thoughts

We could nest the options: nitro.options.prerender.retry.attempts and nitro.options.prerender.retry.delay.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codecov]

Codecov Report

Merging #1534 (ab2be85) into main (b42a432) will decrease coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1534      +/-   ##
==========================================
- Coverage   76.43%   76.38%   -0.05%     
==========================================
  Files          76       76              
  Lines        8008     8025      +17     
  Branches      810      806       -4     
==========================================
+ Hits         6121     6130       +9     
- Misses       1885     1892       +7     
- Partials        2        3       +1     

Files	Coverage Δ
src/options.ts	96.31% <100.00%> (+0.01%)	⬆️
src/prerender.ts	86.11% <100.00%> (+0.16%)	⬆️
src/types/nitro.ts	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[pi0]

Since we use ofetch, i am wondering if we can make use of retry feature. Also was thinking to call it retry / retries because it is additional attempts (and 0 means once as default). tries: 0 has no meaning.

[Hebilicious]

Since we use ofetch, i am wondering if we can make use of retry feature. Also was thinking to call it retry / retries because it is additional attempts (and 0 means once as default). tries: 0 has no meaning.

The ofetch implementation doesn't support a configurable delay. Should I use it regardless ?
I will refactor to retries instead of tries.

[pi0]

The ofetch implementation doesn't support a configurable delay. Should I use it regardless ?

I am positive to include it upstream. PR also welcome 👍🏼

[Hebilicious]

Tagging as pending until unjs/ofetch#262 is merged

[rudolfbyker]

Thanks for working on this!

Just my two cents about tries vs retries: #1469 (comment) Indeed, tries: 0 does not make sense. That should be an error, just like tries: -1 or tries: "foo". However, it's still less confusing to have tries: 1, tries: 2, etc. than retries: 0, retries: 1, etc. If you feel this is nit-picking, just ignore me :)

[Hebilicious]

@pi0 I've rebased this with latest ofetch 👍🏽

[pi0]

❤️