It appears that I have encountered a situation where the page, or rather the page journal, may be too large for wiki to handle. I've been forking the Tracking Down Covid-19 Origin page to my site, but yesterday when I tried forking an update the result was a page with a yello halo, which I ask about on Questions About Federated Wiki.
You may observe that page has a very long journal and I've been wondering whether that might end up causing problems. It might be that the JSON page has simply become too large to fork over to the server fast enough.
Page too large to save
I encountered the yellow halo, and started removing embedded YouTube videos to gain back page load speed. Please try to fork the page again, I found I needed to use Frank's fork as a backup 3 or 4 times for page recovery and lost edits.
I am very leery at inserting images because with modern phone cameras default to increasingly large images. I often will resize images before inserting into a page (ChromeOS makes resizing more convenient than MacOS).
I do wonder is there a limit to the JSON page size of number of linked pages on the page, is the yellow halo a ** warning ** ?
I know that Ward would advise to not make such a longer journal. But I found be keeping a long journal, I can establish a timeline that helps uncover what has transpired.
I expect wiki's observable svg will come in handy to show any patterns discovered, vice versa may be smarter for discovery. I am not sure how to author in diagrams before-the-fact (after-the-fact seems natural).
//
I removed the last embedded video [Jon Stewart on Stephen Colbert's Late Show and Wuhan Lab / Hersey's Chocolate Factory analogy].
After adding little more to the JSON page, I noticed the embedded video sticking to my mouse cursor. I saw this happen after I inserted about 6 images, shortly before the page was lost. Leaving the title orphaned (page had ran out of memory) -- but not today. My PC is a Chromebox with 16 GB memory running ChromeOS Version 92.0.4515.56 (Official Build) beta (64-bit). Intel Kaby Lake 1.8 GHz 2 threads with about 13.44 GB available (very simple PC).
//
Looks like I need to park this page or split it in some way. A partial-fork would be useful UX.
github
I submitted a github issue 272 page 
Frank McPherson 2021-06-21 Update
After I wrote the following I clicked on the github issue page above and read that there appears to be a 5mb limit on page size at the server level, so that appears to be what is being encountered.
I saw the newer version of the Tracking Down Covid-19 Origin page and note there have been many edits. Scrolled down and clicked the fork button on the journal. After the first time I did this I clicked the browser back button right away, and when I clicked the page link from Recent Changes I saw my original page but no yellow halo. As if the fork didn't happen. Tried again, this time let the browser sit for several minutes, and that still didn't make a difference. What I don't know is, when one forks a page in wiki, where is the processing done? In the browser? On the server hosting my site?
I think are two potential areas that could cause this problem, the first is the actual size of the page, the second is the journal. The page size is really mostly text, even video and photos are embeds hosted on another server, though loading those embeds could be taking too long. The other potential problem area is the size of the journal,the one on that page is the longest that I've ever seen.
Might the developers consider a way to re-baseline a page that effectively resets the journal? Per the github issue I think a utility might be in the works.
Page Tools
Compressed Journal
Concussion
Page with compressed journal can now be forked without encountering the yellow warning frame, page is not saved (because Page Too Large)