[BUG]The new lazy loading is not a bust for me

As the DM, I like to not open a sheet till I absolutely have to.  That said, this new lazy loading shit has busted some keys that otherwise performed admirably.  I now have to actively open the players sheets to view attributes and that is annoying as all hell.   Please test your patches thoroughly.  

Can you give a repeatable example? Most of the problems were fixed quickly after they were found.

Pretty sure today was a patch day as everytime they change the code on us they force a new login.  Either way that is just a macro calling @{charactername|experience} of 5e by roll20 sheets of 7 different players, and the character Shayla is the only character sheet that has been opened in the session by a user(me), the rest were blank and as I spammed the button slowly other sheets started showing up there, presumeably because I'm silently loading the sheets in the background.  

Hmm, I have a Pathfinder game that I just logged into and hit a group macro to display all languages that each character knows. That worked fine without opening any sheets.  All my macro sheets for the Palladium system have been working without needing to be opened... I don't play or run 5E, so I don't have anything established to test that system if there is something different about how that sheet/system loads.

I'll do some testing to see if I can corroborate, but that's not quite the way lazy loading works. Your sheets don't load slowly in the background. They don't load at all until they are specifically polled. (API works differently, you can poll everything without loading a thing into the browser, since it loads in its sandbox on the server), but the mere act of referencing a sheet should cause it to load and shouldn't return attributes until that loading has been done. It shouldn't "come up empty". As for the code patch, it's entirely possible for a small fix, but the changelog hasn't registered anything. For my own part, I frequently have to re-log in after just switching machines or restarting my computer. I'll build a macro like you suggest, save it and then run it on a fresh restart and see what I get.

keithcurtis said: I'll do some testing to see if I can corroborate, but that's not quite the way lazy loading works. Your sheets don't load slowly in the background. They don't load at all until they are specifically polled. (API works differently, you can poll everything without loading a thing into the browser, since it loads in its sandbox on the server), but the mere act of referencing a sheet should cause it to load and shouldn't return attributes until that loading has been done. It shouldn't "come up empty". As for the code patch, it's entirely possible for a small fix, but the changelog hasn't registered anything. For my own part, I frequently have to re-log in after just switching machines or restarting my computer. I'll build a macro like you suggest, save it and then run it on a fresh restart and see what I get. I spun up the session from idle, opened the druids sheet to edit something, closed it, realized I rolled an npc encounters rolls publicaly and spammed chat a few to clear their log of anything visible and thats when I noticed over the course of those spams as the default template was spitting out 1, for a bunch, then 2, then 4, then finally 7 towards the end.  

In the act of reproducing this error I noticed that if you dont spam the key, the macro instead sits there, nothing happen, for a while, presumeably because something somewhere is opening the sheets to get the details, there is a 3-5 second delay before that initial press happens.  When I spammed the key it must have triggered some sort of threshold and the chat parser just pushed out what it had available to keep things going?

What were spamming the chat with? With this macro: /w gm &{template:default} {{name=XP Test}}{{GlenJone=@{GlenJones|experience}}}{{Jackie Hammer=@{Jackie Hammer|experience}}}{{Hero=@{Hero|experience}}}{{Krizzzlak=@{Krizzzlak|experience}}}{{Vaunea=@{Vaunea|experience}}} This is what I got before (when I had opened each sheet to put in some XP value) and after a reload while holding down shift to force a fresh cache. It took fractionally longer to run the second time because of the background load, I presume, but if I hadn't just run it before the restart, I wouldn't have noticed a difference.

Verified under another browser just to make sure. Same results.

The step you are missing is spinning up from idle.  Your session is still spun up, those attributes have been called and the chat will push out the attributes when you call them, I don't know of a way to idle a session other than leave for a while, but either way I just reproduced it in my session again, this is a niche issue, no idea if it has implications elsewhere.  I have to imagine though that this will cause unwanted lag/response times for DM's rolling npc initiatives without having first accessed and opened their sheets once.  I don't think its our actual pc's load times that is the issue, I think that their new setup is not actively racking the sheets till the first call to them.  I don't know how group init will handle things I'll report back when I get one of my sessions idled again and test a mass roll of initiatives.  

Went to see if the session spun down and noticed this as the only message in the sandbox: Was not there earlier when playing around in the session, cannot tell you what its from as theres no error report.   Only things I did in the session was multiselect and run !group-init a couple times and that same macro above a couple times.  And no, my players names and character names do not have abnormal characters.  

DM Eddie said: The step you are missing is spinning up from idle.  Your session is still spun up, those attributes have been called and the chat will push out the attributes when you call them, I don't know of a way to idle a session other than leave for a while, but either way I just reproduced it in my session again, this is a niche issue, no idea if it has implications elsewhere.  Reloading while holding the shift key down will completely reload the game. Loading it in another browser does likewise. The character attributes load into browser memory (including cache), not the server. There's no other place for it to exist. Except the API, and that's a different bucket, as discussed above. To re-re-verify this, I opened up a completely different game, my library campaign, which I rarely open directly. I changed "experience" to "strength" because I don't use the experience field, and did not want to invalidate the test by adding a value. Again, a fraction of a second, all fields reporting and in a campaign larger than my normal campaign by several times. I didn't even select the characters in question. Something appears to be happening in your game with that macro, granted, but there's no evidence that it's due to a systemic failure of lazy loading. As for the API message you posted, again, that's a different thing. getAttrByName is an API command, and has nothing to do with lazy loading or the internal code of Roll20. It would require some testing and poking around to determine where the API report is coming from.