User pages link to out-of-date charms

[johnsca]

It looks like the new charm push + publish process doesn't update user namespace pages.

For example, the first charm on u/bigdata-charmers, "apache flume hdfs" links to revision 4 but it should be revision 6.

Another example is u/3-bruno where "quobyte registry" should link to revision 4 but links to revision 2 instead.

The search results page returns the expected links, as does leaving off the revision on the URL.

[chuckbutler]

I can confirm this behavior extends beyond just the user page. I've pushed ntpmaster which originally was a bzr ingested charm.

https://jujucharms.com/q/ntpmaster?type=charm -- see the charmers owned revision listed down under community

This appears to effect the primary store listing as well

[chuckbutler]

The same behavior appears to have struck a rev of elasticsearch

https://jujucharms.com/elasticsearch/trusty/15

This is the head that was pushed today. When looking through the store, elasticsearch brings me to revision 6.

The historical URL structure also leads to a 404:

https://jujucharms.com/u/charmers/elasticsearch/trusty/15

However the parent listing - of https://jujucharms.com/elasticsearch will place you on the correct revision.

[bac]

Using the CLI I see this:

$ charm show cs:apache-flume-hdfs id perm
id:
  Id: cs:trusty/apache-flume-hdfs-6
  Name: apache-flume-hdfs
  Revision: 6
  Series: trusty
perm:
  Read:
  - everyone
  - bigdata-charmers
  Write:
  - biodata-charmers

So the correct data are in the charmstore.

[chuckbutler]

@bac - this ties up with a conversation we had on IRC this morning. I believe the issue is in theblues_browser and may need to be xreffed there

[bac]

I can reproduce it locally so I'll investigate.

[bac]

@johnsca and @chuckbutler Thanks for the bug report. I've found the issue and we'll work on a fix shortly.

The new issue is https://github.com/CanonicalLtd/blues_browser/issues/1234