Closes #6909: LRC hashes injected while SaaS is visiting

[Miraeld]

Description

Fixes #6909

Type of change

• 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).
• Sub-task of #(issue number)
• Release

Detailed scenario

• Manually delete the LRC data of a page to ensure there is no LRC data for this page. Make sure the LRC feature is enabled.
• Clear the cache and visit the page with nowprocket=1&no_optimize=1&wpr_imagedimensions=1. LRC hashes must be added to the page.
• Check the DB, the LRC data must have been stored.
• Clear the cache again. Visit the same page. LRC hashes must not be injected.

Technical description

Documentation

We add a trigger to make sure hashes are added.

New dependencies

Risks

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots 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.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 7999ed21	❌ 20.24% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (7999ed2)	Report Missing	Report Missing	Report Missing
Head commit (005941b)	37956	9516	25.07%

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 (#6919)	583	118	20.24%

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 stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.01% (target: -0.10%)	❌ 0.00% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (d7a5719)	37925	16540	43.61%
Head commit (5f9f34b)	37926 (+1)	16543 (+3)	43.62% (+0.01%)

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 (#6919)	2	0	0.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 stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[Miraeld]

Hasn't pass review yet, but I allow myself posting this screenshot, which is a result of the DB after a warm-up

We can see pages with hashes while it was full empty before.
Pages that are empty now are normal. It should be empty.
I did the following process:

1. Manually delete the LRC data of a page to ensure there is no LRC data for this page. Make sure the LRC feature is enabled.

2. Clear the cache and visit the page with nowprocket=1&no_optimize=1&wpr_imagedimensions=1. LRC hashes must be added to the page.

3. Check the DB, the LRC data must have been stored.

4. Clear the cache again. Visit the same page. LRC hashes must not be injected.

5. Clear performance hints to trigger a warm-up. After a few minutes, LRC data must be available in DB and the rows must contain hashes. (Some inconsistencies can occur, it happened to me once or twice over 15 tries to see a page with empty result while it shouldn't).

[jeawhanlee]

Good Job Sir
What do you think about having an integration test for this filter: rocket_critical_image_saas_visit_buffer callback?

[MathieuLamiot]

Tested and looks OK on http://mathieu.e2e.rocketlabsqa.ovh/.
About #6894, I can't reproduce now with this version on mathieu.e2e.I triggered warm-ups several times and consistently get only one row with empty LRC hash list (contact-us, mobile version) which seems normal.

I'll keep this in review pending closing @jeawhanlee comment about tests. But then, it can be considered QA Done :)

[Miraeld]

Integrations tests have been added @jeawhanlee , can you confirm and move it to QA Ready ?

[MathieuLamiot]

Only tests changed since I manually checked the fix, so let's consider the QA Done