NoCanonicalUrl using api to fetch bug comments

[Diogo Matsubara]

OOPS-2016A8 NoCanonicalUrl: No url for <Message at 0x1336dc90 id=10076693> because <Message at 0x1336dc90 id=10076693> broke the chain.

[Martin Pool (mbp)]

dupe of bug 607438?

[Diogo Matsubara (matsubara)]

I don't think this is a dupe (If it is, then it's a regression). The most recent OOPS like the one reported is from today: OOPS-2020CK40

[Richard Harding (rharding)]

This bug is caused because the comment in question here (#11) is a Message
object with a parent that is another Message object. That is the message that
the milestone was changed from undefined -> 4.4.0.

Not all messages are exposed to the api as a resource. The lazr.restful needs
to be able to generate CanonicalUrls for all properties of the original Message,
including the parent. That parent could be a legitimate resource. The main path
of information is:

lib/canonical/launchpad/webapp/publisher.py - line 496 -
    urldata = ICanonicalUrlData(current_object, None)

Which eventually gets into the adapter code:

message_to_canonical_url_data()

This adapter has an else check that attempts to determine the CanonicalUrl for
the plain Message object (the parent) passed in, which returns None, and
causes the publisher to raise a NoCanonicalUrl exception.

lazr.restful should expect all of these properties to have a CanonicalUrl for
it. To fix this, we'd need to determine some method to expose all messages
via a CanonicalUrl that the api could then link to. The adapter could then be
updated to generate this.

I don't have time right now to implement this exposing, but hopefully this
helps the next developer down the road.

[Robert Collins (lifeless)]

another way to fix it would be to have that .parent attribute be None initially.

Why are we not exposing the message on the API today? Is there a good reason? If so, having the parent set to None is probably the simplest and best way forward.

[Curtis Hovey (sinzui)]

I think we want to rethink this issue. The context here is reading bug messages. All we ever promised was bug messages. bug messages are not threaded, though the underlying model does permit them to be, and the restful rules see that. The parent has always been exported on IMessage, so we cannot remove it. I think we want to ensure that parent is ignored.

We do not want to make links outside of the bug's context because this serialisation mechanism is making links that might contain a private object. Messages are subordinate to their artefact; users may get 403s if Lp wants to make a a link to something's message that the user is not permitted to access.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r16331 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/16331>.