3.16 - Handle different errors from the beacon script

[wordpressfan]

Description

Fixes #6570

Documentation

User documentation

Now we handle two different scenarios:

1. Script timeout: If for any reason, the script took more than 10 seconds, this will fire the ajax call to save failed row in the DB not to load the script again, to simulate this you can use the following JS code:

function wait(ms){
   var start = new Date().getTime();
   var end = start;
   while(end < start + ms) {
     end = new Date().getTime();
  }
}
wait( 15000 );// This will wait for 15 seconds.

Exactly here:

wp-rocket/assets/js/lcp-beacon.js

Line 26 in 5fc1fd4

2. Script error: Also if for any reason we got an error from the script, we will send the same ajax request to set a failed row in the DB.
   You can simulate this by putting any strange line exactly inside the try block here:

wp-rocket/assets/js/lcp-beacon.js

Lines 16 to 21 in 5fc1fd4

	// Use _generateLcpCandidates method to get all the elements in the viewport.
	const above_the_fold_images = this._generateLcpCandidates( Infinity );
	if ( above_the_fold_images ) {
	this._initWithFirstElementWithInfo( above_the_fold_images );
	this._fillATFWithoutDuplications( above_the_fold_images );
	}

Technical documentation

Explain how this code works. Diagram & drawings are welcomed.

Type of change

Delete options that are not relevant.

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).

New dependencies

List any new dependencies that are required for this change.

Risks

List possible performance & security issues or risks, and explain how they have been mitigated.

Checklists

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables and functions explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
•  I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

•  I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.02% (target: -0.10%)	✅ 100.00% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (b86840b)	37100	14306	38.56%
Head commit (8b623fe)	37115 (+15)	14321 (+15)	38.59% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#6603)	16	16	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy will stop sending the deprecated coverage status from June 5th, 2024. Learn more}

[MathieuLamiot]

Thanks for the PR!
Looking at the code, I don't understand how the script deals with the AC of "infinite loop"? It looks like there is no timeout set and that we only check the execution time at the end of the script (if we reach it). Am I missing something or is there any reasons to not cover this? Thanks

[MathieuLamiot]

Thanks for the update. Do you think a closeTimeout would be beneficial too, to avoid a timeout running in the background when it's not needed anymore?

[wordpressfan]

Thanks for the update. Do you think a closeTimeout would be beneficial too, to avoid a timeout running in the background when it's not needed anymore?

That's a good idea, I pushed now a code that uses clearTimeout function

[MathieuLamiot]

Tests looks OK to me to catch errors. Infinite loop is not prevents if we brutally do while(true) bu that's probably expected as the event loop is not freed? (or something like this). I'd say we should go ahead and merge.