amphtml: [amp-subscriptions] Fetch entitlements timeout error on Android Google News app
What’s the issue?
Fetch entitlements timeout error when opening an amp page from the Google News Android app. The page must have the amp-subscriptions extension with a authorizationUrl that is using the SOURCE_URL substitution variable.
How do we reproduce the issue?
- Add the amp-subscriptions extension to an amp article;
- Add an authorizationUrl that has the SOURCE_URL substitution variable;
- Open the amp page from the Google News Android app(webview url parameter will be equal to 1).
While the AMP Runtime prepares the authorization request(fetch entitlements) it will occur an Error: fetch entitlements failed for local: timeout
. The error seems to be occurring even before the request to the authorizationUrl is made.
Example amp-subscriptions configuration:
<script type="application/json" id="amp-subscriptions">
{
"services":[
{
"authorizationUrl":"https://www.example.com/amp/132456?rid=READER_ID&url=SOURCE_URL",
"actions":{
"login":"https://www.example.com/amp/132456?rid=READER_ID&url=SOURCE_URL",
"subscribe":"//example.com/subscriptions/landings"
}
}
],
"fallbackEntitlement":{
"source":"fallback",
"granted":false,
"grantReason":"METERING",
"data":{
"fallback":true
}
}
}
</script>
What browsers are affected?
Webviews on Google News Android app.
Which AMP version is affected?
I tested on versions 012012232217000 and 012012301722001, both had the same problem.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23 (21 by maintainers)
OK. Then I guess that’s the real root cause. I agree with Dima. The protocol is that AMP runtime expect a messaging channel when seeing
#webview=1
in the URL.If the webview specifies
#webview=1
it means that it wants to supply messaging to adjust some of the page’s behavior. If we remove one dependency now, we’d quickly run into a next one. E.g. acid
generation or anything else. So I don’t think it’s as helpful trying to minimize the deps unless we see a way to bypass them in 100% of cases, which I don’t yet see how to.yes. it was introduced by this PR: https://github.com/ampproject/amphtml/pull/5606/files#diff-8a281cee899c97e8bea38ad6acd584e37576f42b76411813739ba4c2f8660a11R167
if I remember correctly, it was for feature “ALP (AMP Landing Page)” to finish its impression tracking which used source URL to store data that needs to be removed before it is further used as SOURCE_URL
@cramforce could you remind me what the final status ALP is? I think it’s dead?
OK, finally located it:
https://github.com/ampproject/amphtml/blob/df3c52493f4f5905103dce293b5415d6453beb22/src/service/url-replacements-impl.js#L200-L204
this is while resolving SOURCE_URL (not READER_ID), which waits for a 8s timeout here:
https://github.com/ampproject/amphtml/blob/df3c52493f4f5905103dce293b5415d6453beb22/src/impression.js#L78-L82
more debugging, I think the timeout happens here at L52
expandUrlAsync
: https://github.com/ampproject/amphtml/blob/df3c52493f4f5905103dce293b5415d6453beb22/extensions/amp-subscriptions/0.1/url-builder.js#L50-L54The URL passed in is:
My early finding is that
#webview=1
makes AMP runtime to init a messaging channel. which I don’t know if this is desired. https://github.com/ampproject/amphtml/blob/19645e3aa1c516291350add19ea417a416b5f8e9/src/service/viewer-impl.js#L309-L312The key is to understand if there should be a messaging channel for webview. Anyone knows about this use cases?
@kristoferbaxter @alanorozco @dvoytenko