Amphtml: 'src' attribute set to invalid in amp-mustache script

[Dnguye92]

What's the issue?

By simply including the amp-mustache script tag <script async custom-template="amp-mustache" src="https://cdn.ampproject.org/v0/amp-mustache-0.2.js"></script> I am seeing an error from the AMP extension stating The attribute 'src' in tag 'amp-mustache extension .js script' is set to the invalid value.

How do we reproduce the issue?

Can't replicate this inside of a jsbin but even by simply using amp-mustache in the playground (https://ampbyexample.com/playground/) you can see this error in the chrome extension

1. Go to http://jsbin.com/vobolelage/edit?html,output
2. Copy the code on the left side of the bin and past into https://ampbyexample.com/playground/

What browsers are affected?

As of right now I only see the error on Chrome on Desktops

Which AMP version is affected?

<script async src="https://cdn.ampproject.org/v0.js"></script>

[jpettitt]

Confirmed - search console is telling people to upgrade to 0.2 but 0.2 is failing the JS validator

[choumx]

Looks like there's some skew in the deployment pipeline.

version: 0.2 and deprecated_version: 0.1 were added in the same PR: https://github.com/ampproject/amphtml/pull/16201/files#diff-920b14e1d472072d04dcbfc41ab50294R29

[cramforce]

Versions should not be introduced and deprecated in the same release cycle for many reasons.

[cramforce]

@Gregable for when the skew would be resolved.

[jaygray0919]

it's difficult to over-emphasize @cramforce Malte's maxim. It's central to the immutable systems concept practiced at Netflix and advocated by folks like Rich Hickey (https://en.wikipedia.org/wiki/Clojure). You can't breaking existing systems; folks have to voluntarily subscribe to new services. @choumx William has compelling reason to use a new service, but it's my decision when to roll-it-out.

[cramforce]

@jaygray0919 Note, that AMP itself is deployed as an an "evergreen" system and it isn't possibly to version lock to the patch level.

The version skew issue in the validator was resolved. @choumx We can call this fixed, right?

We'll follow up with a quick postmortem, since was a process problem.

[choumx]

Yes, verified that amp-mustache-0.2.js is now valid on both JS and C++ validators.

[Gregable]

This is now resolved.

Validator rules were updated to simultaneously add support for 0.2 and add a deprecation warning for 0.1. These rules get released at different schedules to different Google products. In this case, Search Console picked up the rules first a few hours ago and began displaying the deprecation warning. The Javascript Validator interfaces, such as the extension you noticed, picked up the change a few minutes ago.

In order to see the changes in your extension faster, you may need to clear your cache / restart your browser. You may also just try to force refresh the code here: https://cdn.ampproject.org/v0/validator.js

[afterdesign]

Hi.

Since yesterday I'm getting a lot of errors in search console and it's referencing the URL to amp-mustache v0.2 version:

User-authored JavaScript found on page: The attribute 'src' in tag 'amp-mustache extension .js script' is set to an invalid value

The AMP validator in chrome is saying that everything is ok.

[nikse]

I'm having the same issue as afterdesign. Included v0.2 yesterday because it started validating in browser console. Woke up today and have a ton of errors saying 0.2 is not valid and still have a ton of warnings saying to upgrade to 0.2 in the search console

[jpettitt]

We are aware the search console is erroneously flagging 0.2 as an error. It's not an error and we're working of getting the messaging fixed. This is a knock on effect from the version skew problem.

[shinsenter]

We have the same problem with 0.2

[stephengardner]

Please publish an article about this, I'm being inundated with complaints by users experiencing this. We have an app that converts pages into AMP. We updated to 0.2 per the error. We need a link to send them saying this is Google's fault.
Help.

[jpettitt]

Best bet is to send them a link to this issue.

[stephengardner]

I really need some confidence that this is being fixed, or a timeline on when............

If we revert back to 0.1, will the warning still show? It says that a commit was pushed to remove the deprecation warning but other users seem to be still experiencing warnings.

Please advise ASAP.

[jpettitt]

It is fixed. Any errors users are seeing are stale. Both 0.1 and 0.2 are considered valid.

[stephengardner]

THANK you.

[mayrop]

Will the url inspection be fixed as well? When I submit a page in the "URL inspection" tool (desktop URL), it still says that the AMP linked version is invalid:

[jpettitt]

Please email me the URL you are testing (same username @google.com)

[jamesshannon]

Is there a link to the PM document?

Will it be limited to the version skew issue, or to this version bump in general? While there's a versioning policy, it seems like there are some practical considerations which AMP needs to address in the future:

1. How do publishers know when a library has been deprecated? Are they required to monitor github and amphtml-announce? It seems that GSC is throwing alerts (and possibly emails) due to its integration with AMP validation. Is it the AMP project's recommendation to rely on GSC to become aware of AMP library deprecation? What about pages which Google doesn't crawl (e.g., SEM landing pages)?

2. According to the deprecation policy an announcement should have been made to amphtml-announce. It looks like this wasn't done.

3. What's the timeline for deprecation? According to the policy, it's 6 weeks. Is that a hard limit? Should there be a hard date somewhere rather than the ambiguous "may become an error in in the future" (which could mean tomorrow or next year)? In other words, is it possible to set expectations better?

3a. Given that we're seeing more complex AMP implementations from more complex publishers (read: enterprise), is the 6 weeks sufficient? Many companies (including Google) have multi-month code freezes.

[cramforce]

We'll share a postmortem (delayed by team offsite) when it is ready. This
rollout was clearly not in compliance with the existing deprecation policy;
and we'll discuss possible amendments of the policy in the PM.

On Tue, Jul 31, 2018 at 3:53 PM James Shannon [e-mail]
wrote:

Is there a link to the PM document?

Will it be limited to the version skew issue, or to this version bump in
general? While there's a versioning policy, it seems like there are some
practical considerations which AMP needs to address in the future:

1.

How do publishers know when a library has been deprecated? Are they
required to monitor github and amphtml-announce? It seems that GSC is
throwing alerts (and possibly emails) due to its integration with AMP
validation. Is it the AMP project's recommendation to rely on GSC to become
aware of AMP library deprecation? What about pages which Google doesn't
crawl (e.g., SEM landing pages)?
2.

According to the deprecation policy an announcement should have been
made to amphtml-announce
https://groups.google.com/forum/#!forum/amphtml-announce. It looks
like this wasn't done.
3.

What's the timeline for deprecation? According to the policy, it's 6
weeks. Is that a hard limit? Should there be a hard date somewhere rather
than the ambiguous "may become an error in in the future" (which could mean
tomorrow or next year)? In other words, is it possible to set expectations
better?

3a. Given that we're seeing more complex AMP implementations from more
complex publishers (read: enterprise), is the 6 weeks sufficient? Many
companies (including Google) have multi-month code freezes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/17138#issuecomment-409393815,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT2HaxiD5D0j6c1qnd80qmQtxKIRPks5uMN_zgaJpZM4Vii7a
.

[stephengardner]

As @jamesshannon has kind of mentioned.

It is absolutely not OK to be notified of deprecation events solely via emails generated by GSC. I'm not sure if it was documented somewhere else and I perhaps missed it, but if there isn't a deprecation timeline map available, we definitely need one.

I mention this again because our app converts 1000s of customers pages into AMP, and when they receive a "Warning - you are about to be penalized in search results" (paraphrased) email, they rightfully flood our customer support with messages that could have certainly been avoided.

Thank you for the update. I think it's now been addressed that there was a screwup. Looking forward to improved standards moving forward.

Cheers

[jamesshannon]

Oh. Another thing around this:

The version notes aren't particularly helpful in for the purposes of deprecation.

• First, how relevant is the version notes for a particular library? It looks like version notes are only used for minor releases (and not patches). But functionality is regularly added to libraries via "patches". Certainly it woudln't be surprising if <svg> features were added and the bundle size was reduced without a major or minor version, and thus that wouldn't typically get added to the Version Notes. If that's the case, then what's the point of having Version Notes at all? Maybe they should be deprecation notes?

• The bundle size comment was confusing. I assumed that that referred to something similar to the the 50kb CSS limit. The actual gzipped JS library size doesn't seem relevant enough for this.

• Last but not least -- if I have dozens or hundreds of AMP pages which I'm responsible for, the description ("Internal improvements may cause minor breaking changes") doesn't really help me migrate to v0.2. What should I be looking for? On which pages? I wouldn't expect that a "minor breaking change" -- especially to mustache templates -- would be immediately visible. With amp-bind and other components, a lot of functionality is hidden under actions. Do I need to (manually) test every action on every page? How do I know that just because I've noticed one discrepancy there might not be others?
  The Deprecation Notes should describe exactly what might happen, and how that might occur. Should I look for unreplaced variables? Or text that's suddenly backwards?

[jpettitt]

We definitely need to do better than

Internal improvements may cause minor breaking changes

Expect that to be covered in the postmortem.

[jerimiahwelch]

@jpettitt ,

We are still seeing this error in Beta Google Search Console for pages crawled yesterday:

We'll wait until they go away before converting all pages to 0.2, but it appears the error is not fixed in Google Search Console Beta.

[Gregable]

@jerimiahwelch The short answer (longer answer in postmortem soon) is that newly processed documents will not have this error and the error will disappear over time as these documents are reprocessed. In other words, the count of this error will only decrease over time at this point.

[jerimiahwelch]

@Gregable Thank you for the explanation. I do see the errors going down over time.

I'm a bit confused because some of those pages with the error report that they were crawled on 8/1, which is two days after the fix was reported as completed in this thread. For my understanding, does it take some time for updates to propagate through the validation system or is the 8/1 crawl date not a precise date?

[Gregable]

There was a secondary issue discovered that only appeared once publishers like yourself began converting pages to use 0.2. It was infrequent, but not resolved until 8/2.

[GoodGun]

same problem appeared also for us, still continues... is there any answer for that reason;

cloudflare shows;

[Gregable]

Please see the attached post mortem on this issue.

Post-Mortem-amp-mustache-0.2.pdf

[Gregable]

@GoodGun it would appear that Cloudflare's validator rules are out of date.

[GoodGun]

@Gregable thanks for your fast reply, we ll discard the cloudflare validator...

[choumx]

As part of the post-mortem action items, we've updated and clarified our versioning policy in #17370.

Moving forward, all extension version deprecations will follow a strict deprecations process including announcement on public channels, community discussion, and constrained timelines to deprecation/invalidation. For example:

A version must not be deprecated until a new version is released and stable for at least 1 month.
A version must not be invalidated until it has been deprecated for at least 1 year.

amp-mustache's version notes have also been updated with more details.

[ampprojectbot]

This is a high priority issue but it hasn't been updated in awhile. @Gregable Do you have any updates?