Performance report returns results not available due to invalid wpcom_performance_report_url option value

[mgozdis]

Quick summary

The value for the wpcom_performance_report_url option is sometimes invalid, which causes the API to return a 403 response and a Results not available message as shown here:

Rather than the option value containing the domain name with the hash, it saved the domain name as false, such as http://false&hash=hashvalue

Screenshot:

User report: 9148283-zd-a8c

Steps to reproduce

It is not currently known how to reproduce, however, a button to launch the site was also displaying sporadically despite the site being launched and public. Clicking the button did not change the behavior of the report not displaying.

What you expected to happen

The report should display.

What actually happened

Results not available is returned.

Impact

One

Available workarounds?

Yes, easy to implement

If the above answer is "Yes...", outline the workaround.

Delete the wpcom_performance_report_url option from the wp_options table and flush cache. The report will then generate and the option should be recreated with a valid value.

Platform (Simple and/or Atomic)

Atomic

Logs or notes

No response

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 9148283-zen
• 9198686-zen

[Robertght]

@mgozdis I added the Droplr screenshot to the original report as links expire.

As we don't have specific steps to replicate, I'm also curious what can break this.

@Automattic/quake is this something your team can investigate?

[vykes-mac]

Thanks @mgozdis for reporting this. does it happens even if the user re-run the tests? can you provide the SA or user? the linked zendesk ticket does'nt seem to work

[mgozdis]

@vykes-mac Yes, re-running produced the same error. The only way I was able to resolve was by deleting the wpcom_performance_report_url in the database.

I'll note that they or another HE also attempted testing this on a staging site. The same issue existed there since it syncs the data exactly as is.

That could potentially introduce other issues when syncing staging/production sites if it ends up using a value for the wrong site. We may want to preserve that value from being overwritten during syncing, but that's a separate issue that would need to be tested.

[vykes-mac]

Thank you @mgozdis , I am able to reproduce on staging sites. Maybe that's where the error first occurred and was further synced to the production site.

[mgozdis]

With the site that reported it, I don't think they ever synced staging back to production. They deleted the staging site already so there are no logs. It may be an issue with how the value is initially saved and potentially reproducible if a site is not launched, private, etc.

For preserving values when syncing, this may be helpful to read as there is a Protected_Options_Action class: D166504-code

[vykes-mac]

if a site is not launched, private, etc.

If a site is not launch or is private, performance test is not executed.

[mgozdis]

On the site that reported it, that launch your site info would "flash" for a split second before the error even though the site was launched and public. They had Prevent third-party sharing enabled, but changing that and making the site private or coming soon and back to public had no effect either.

[vykes-mac]

I'm not sure how to reproduce this, but from the error I can see that the report url was saved http://false&hash=hashvalue , the false suggest there was an error with the url return from the backend, in this case we shouldn't have saved that url but allow the user to re-run the test. I see in the code where the url is saved even though "false" is returned as the url. This should be fixed to prevent this issue and so the user will be able to retry without a faulty url.

[aisajib]

This came up on 9198686-zd-a8c too, which @ajaykj fixed.

[upwardmomentum84]

Another occurrence of this here: p1736781440657919-slack-C03TY6J1A

[vykes-mac]

I'm going to add a guard to prevent these scenarios and merge that code

[vykes-mac]

I've added a guard to prevent this issue here . Please feel free to reopen if we continue to get reports