There is no magic involved.
Term lookups are performed differently for different entity types (because the data lives elsewhere), but in a non-hacky fashion (and it doesn't really matter where the data comes from or how it's retrieved anyway)

AFAICT, most operations seem to be working fine.
The one that don't are either:

• irrelevant (e.g. resolvePropertyId - MediaInfo's aren't properties; or getDescription - it works, but MediaInfo's don't tend to have descriptions...)
• use SiteLinkLookup (getEntityIdForTitle and getSitelink) - I'm not even sure we'll need these for MediaInfo's - if we do, we can implement that later on!

Other lookups seem to work just fine!

In T223792#5592264, @WMDE-leszek wrote:

Apologies for being hard to reach recently @matthiasmullie.
I've submitted a change pair https://gerrit.wikimedia.org/r/544972 + https://gerrit.wikimedia.org/r/544973 with a simple proof-of-concept of what would be my idea how to solve this. I am not certain how to verify that all lookup operations are working as expected, so I would appreciate if you could have a look.

In T223792#5563683, @WMDE-leszek wrote:

I should be able to help with it @matthiasmullie . Looking into it...

In T222867#5552682, @Ramsey-WMF wrote:

Heads-up - we're going to start addressing some of these issues soon, but there's a refactoring patch that has to go out first (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikibaseMediaInfo/+/528825/).

Update: while above patches got merged, Lua still won't work by next week's deployment (at least not until some more issues are straightened out, but they may require some more work)

@OlafJanssen It's not immediately clear to me exactly what's going on.
Did the new user start seeing this error message immediately, when the very first thing was being submitted? (in which case this is probably some yet unknown bug)
Or was it only after having already submitted a few things that it showed up? (in which case I suspect the user was rate limited - only a certain amount of edits are allowed in a short period of time for new users)

And unassigning myself - I don't want to claim this. Anyone can pick this up, work on any number of the acceptance criteria, and pass it on.

I've spun this off into multiple tickets - one per "category" - and I'm pulling this first one into "current work".

a) is nothing to worry about: already fixed in prod T231488

I backported the patch that I believe should fix this - are you still able to get into this stuck state now?

I believe all of those things have now been fixed - can you do another run on labs to verify? :)

Ok cool, thanks for the info!
I suspect the CORS (CSP) errors in console have nothing to do with it (see T135963), but the "abort is not a function" might.

That's on beta, I suspect?
What steps did you do to trigger this? Just added the new property, and that's how it then appeared? Or did you start typing an item? Or did it only appear once you added the other statements or edited anything else?

It's greyed out because that specific datatype has no proper support yet (e.g. can't edit the coordinate)
It's something we want to do soon, though: T224060

@Ramsey-WMF Is this still broken for you? AFAICT, it works fine now.

Some of last week's refactors probably solved this.
Closing since I can no longer reproduce this, but if anyone else still sees this, please reopen!

@LucasWerkmeister Yes - I'm in Stockholm. I'll take a look at your suggestion and then come find you!

Things >30d old will expire and get proper treatment, things < 8d should already have correct html in cache.
It's just the things in between, I believe. Basically the "active enough that it *is* in cache (most likely only when bot ran), but not really too active because it's not really recent".
I believe the bad caches size is small enough, the issue trivial enough, and the tempfix (?action=purge) easy enough, that we should not put more effort into it, and just let caches expire.

It looks like we may not need wb_terms (or the redesigned store) at this time. Declining ticket for now.

I'll decline this task, since we probably won't end up wanting or needing wb_terms (not yet, at least).
This could be reopened if at some point later on we find that we do have a valid usecase for them.

I was thinking it'd make most sense to use the existing code & structure already used by Wikidata.
But I've since learned about the reasons for not using wb_terms (I figured it was just a case of not having implemented it because there had not been a need for it yet)

Confirmed fixed on test-commons.

This may be something we'll want to cherry-pick (or postpone enabling other statement until new branch gets to commons, next Wed)

I *think* this is a testcommons-specific edge case.
The SDC content should have 'display: none' by default on all other wikis, but since this one also has MediaInfo, it's actually getting displayed (but since it's not inside the own wiki's content div, it's not being hooked up properly)

Can you still reproduce this? Or anyone else?
I can see the qualifiers immediately, both logged in & out.

Closing - we're getting notifications in Slack!

Nope, you're not mixing it up with something else; it is indeed undergoing redesign.
I've created T227848 to look into that, and what it'd mean in this context.

As mentioned in T223792: Current Wikibase Lua support seems able to deal with MediaInfo entities already - it just can't find them.
If we start writing MediaInfo entities to wb_terms, it all starts to work.
However:

• we'll need to run a maintenance script to populate the index for older entities: T227847
• IIRC, wb_terms is currently undergoing redesign/migration - we need to figure out what that means for us (wait until that is done? migrate? how?) T227848

I've create new tickets for those things, and am considering this one done.

It looks like the Wikibase Lua support can mostly deal with MediaInfo already, except that it can't look up the MediaInfo entities.
Unlike Wikibase properties & items, MediaInfo entities are not currently stored in wb_terms.
If MediaInfo starts writing to wb_terms, Lua's functions also start working.
wb_terms is in the process of being redesigned/migrated, though, and I have yet to look into that.

Should be done (slack notification) - won't be able to test until patch for T219815 gets merged