Right now, there are 8k+ MediaWiki jobs in the queue for geokb.wikibase.cloud. I started a job to process these (which likely resolves the issue):

$ WBS_DOMAIN=geokb.wikibase.cloud ./runAllMWJobs.sh                                                                                                             production
job.batch/run-all-mw-jobs-vbrnn created

Job is now finished and https://geokb.wikibase.cloud/w/index.php?search=chemical+element+group&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1&ns120=1 also yields a response.

Thank you for taking a look at this issue. A bunch of items that I pushed yesterday evening seem to be coming up in search just fine as well. I assume that regular processing for the search index should happen automatically and be close to real time. I built infrastructure years ago between MongoDB and Elasticsearch where we had to deal with scaling issues of keeping an index up to date in real time with the data store. I haven't dug enough into your architecture here yet to understand it, but I can imagine it's a challenge.

I'm super stoked about what you guys are doing with this project! I look forward to continuing to leverage it in our use cases and contribute where I can. Way cool!

@Skybristol There is another ticket about that architectural issue you are mentioning in case you are interested in following along: https://phabricator.wikimedia.org/T330389

This is continuing to be an issue for me on another use case I am working through. I'm building out information associated with the Facility Registration System operated by the US Environmental Protection Agency. This information is incompletely and inadequately organized into Wikidata, so I am working on methods to process source data and organize into items. I've started on the two classification systems in use which are also incompletely referenced in Wikidata.

As I'm pushing items into a new wikibase.cloud instance with code, I find a major time lag in when the items show up in the UI, presumably via indexing. This has applied to both items and properties. There is a lag in when new properties show up on Special:ListProperties. I generally do see items (but I haven't checked comprehensively) on Special:RecentChanges, but I can't turn those same items up in a UI search. I have been able to return items and properties right away via SPARQL (I assume that's not index dependent).

This is also impacting implementation of formatter URL, which I implemented for five different external ID properties after pushing a batch of 2K+ items. I now have some items where the formatter URL settings have taken effect and others that are still catching up. I've seen chatter in Telegram on formatter URL perhaps not working properly to build links in the UI from ExternalID properties until indexing catches up.

This isn't a massive deal in some use cases; I don't have to worry about parallelizing my processes if it's going to take items a while to be fully integrated anyway. But I have stuff coming up I want to be able to do where I need to push millions of items and claims (2.7M EPA facilities). It would be good to know if this is pushing the beta too far and if the wikibase.cloud team is working out Elasticsearch configuration and scaling issues in a way we might be able to replicate in alternate dedicated Wikibase infrastructure. Is something like the RaiseWikibase approach going to work against a wikibase.cloud instance, or am I going to blow something up?