Item9482: % META might show data of a totally unrelated revision

By default it should display the latest revision unless a different rev has been specified by url params. Right?

It doesn't. Instead it displays what was left behind in the topicObject during the course of the preceeding rendering steps.

Hard to reproduce as %META{"form"}% displays fine in pattern but not in nat.

See irc logs starting at http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2010-08-17,Tue&sel=278#l274

-- MichaelDaum - 17 Aug 2010

Wrong. it displays the current rev, whatever that might be. In a viewed topic, it shows the currently viewed rev. In an included topic, it shows the rev included.

Without a testcase, or a description of how to reproduce this, I can't do anything.

-- CrawfordCurrie - 17 Aug 2010

As I said it is hard to reproduce. Still I get the error. It is a sever bug.

Do we agree that by "current" we define "the revision to be displayed currently"?

Please notice, that this might significantly differ from "the revision currently loaded into the topicObject" as being passed to %META.

The different behaviour stem from the fact that the very topicObject being used was formerly loaded with a different version which is not necessarily the one to be displayed.

It does not matter how a different non-current revision got loaded into the topicObject. Presumably that happed during the course of some plugins reading arbitrary revision info.

In short: there is nothing in the code to make sure %META reads the current revision of a topicObject to be displayed.

-- MichaelDaum - 17 Aug 2010

No, and there shouldn't be. If the wrong revision is passed to the META code, then it's the caller that is at fault. For example, a call to $meta->expandMacros will use the revision currently loaded in $meta. $meta might be the object created in UI/View, or it might be created somewhere else entirely; or some other piece of code may have force-reloaded the object with a different version (perhaps even a plugin?). That's why it's impossible to track down without specific debugging information.

-- CrawfordCurrie - 18 Aug 2010

Would you at least consider it an error when %META{"form"}% displayed the wrong revision's form? Because that's what I get.

Here's how to reproduce the bug reliably:

1. create a topic and attach form A to it
2. edit the topic and attach form B to it and click force new revision
3. add %REVINFO{rev="1"}% to the topic to make sure REV 1 gets loaded, the one with the old form A attached to it
4. save

ERROR: : You'll see form A being displayed at the bottom of the page, although form B is currently attached.

-- MichaelDaum - 18 Aug 2010

The root cause is that meta objects can reload a different revision. That's a conceptual problem that has caused several problems on trunk in the past. There might still by means to pollute a meta object with a different revision, which is then reused later on, i.e. the "current" meta object as being passed around by the TML renderer. This one is sacred.

For now I didn't find any other way to trigger the reported error, now that REVINFO has been identified evil and been fixed.

Still, that's only working on the symptoms.

-- MichaelDaum - 18 Aug 2010

Reopening this bug as I just found out that %META{"attachments"}% returns an empty string for a meta object that hasn't been loaded yet.

As far as I see, %META must have loaded any revision at least, i.e. make sure there is one loaded.

-- MichaelDaum - 18 Aug 2010

erm, what's the call path? It shouldn't be possible for META to be called without a revision loaded.

-- CrawfordCurrie - 19 Aug 2010

Also, is this still the case after the most recent checkin against Item9487 ?

-- CrawfordCurrie - 19 Aug 2010

Not anymore. Works now. Great. I am still a bit nervous about this. So I will keep poking around for a few days. Closing this item - will reopen a new one even if related.

-- MichaelDaum - 20 Aug 2010

Commenting is disabled while not logged in