API no longer triggering sheet workers

Greetings folks,

Currently APIs are not triggering sheet workers as they should. The cause of the issue has been identified and I am working on a bug fix now. Unfortunately this will likely not be completed for before the weekend. I apologize for the inconvenience this may cause API users. Rest assured we are working to find a resolution to this issue.

Thank you,

Cassie

@cassie Is this resolved?

Greetings Evan,

I believe it has not. Can you give it a try and confirm it is working for you?

Thanks,

Cassie

Cassie

Could this be related to an API error that's been seen by multiple people:

Greetings Skepickle,

That's a different issue related to an infrastructure upgrade.

So I guess that the issues still has not been resolved? 
Our character sheets for our FFG SW game still is not responding.

Hi Cassie,

Is there any update on when this issue will be resolved? I'm still getting no joy on this issue.

Greetings,

It is currently not fixed and I have asked the powers that be for an update. Sorry for the delays.

- Cassie

Thanks, Cassie!

Is this issue the sheetworker issue or is it unrelated?

Hello API fans.

Thanks for your patience while we work through this issue. What we're finding is inconsistencies in Sheet Workers called from the API, but I wanted to ask for your help with specific APIs and Character Sheets that are not working. We don't need every failure, but enough to fully encapsulate the scope of the issue.

Please leave a comment with the API, the Character Sheet, and the error you received.

Thanks Kenton,

I'm experiencing problems with the 5E OGL sheet when toggling Global Damage Modifier via ChatSetAttr.

The error message is 

"GLOBALDAMAGE"
"ReferenceError: update_attacks is not defined"
"ReferenceError: update_attacks is not defined\n    at Object.eval [as -LcY3Gj_eveqSdhNFnNf//repeating_damagemod_-LcY3bPUU4GzEMcGqZwZ//0.06484943159589673] (eval at messageHandler (evalmachine.<anonymous>:284:6), <anonymous>:4169:25)\n    at _fullfillAttrReq (evalmachine.<anonymous>:259:31)\n    at messageHandler (evalmachine.<anonymous>:296:6)\n    at process.<anonymous> (/home/node/d20-api-server/node_modules/tiny-worker/lib/worker.js:60:55)\n    at emitTwo (events.js:106:13)\n    at process.emit (events.js:194:7)\n    at process.nextTick (internal/child_process.js:766:12)\n    at _combinedTickCallback (internal/process/next_tick.js:73:7)\n    at process._tickCallback (internal/process/next_tick.js:104:9)"

Cheers

Sheetworker API failure example

API Script: ChatSetAttr

Sheet: D&D5e by Roll20

Command that fails: !setattr --sel --repeating_damagemod_$0_global_damage_active_flag|1

Expected Behavior: Check referenced Global Damage modifier and activate it

Actual Behavior: Checks box, but Global Damage Modifier does not actually activate. You must toggle the box manually for this to happen.

More Info: The inverse of this comand: !setattr --sel --repeating_damagemod_$0_global_damage_active_flag|0 works identically: toggles box off, but does not deactivate modifier. ChatSetAttr has setting to "use sheetworkers"; this has been set to ON. This solution may be related to the D&D5e by Roll20 sheet. Similar steps do work on Shaped sheet for 5e.

Sheetworker Failure Example

API Script: ChatSetAttr

Sheet: D&D5e by Roll20

Command that fails: !modbattr --silent --sel --exhaustion_level|?{Add or Subtract?|Add,+1|Subtract,-1}

Expected behavior: Exhaustion level incremented by 1 (plus or minus) and description of exhaustion effects updates on character sheet (disadvantage at level 1, speed halved at level two, etc.)

Actual behavior: Level increments, but nothing appears in exhaustion field except the words "No effect" (as if no exhaustion is present) and odd characters (white question marks against black background)

More info: Toggling the exhaustion levels up or down manually in the sheet produces the desired description in the field. It's just not working via API.

I can't get the 13th Age API working properly. Commands like !edie and !setup do nothing afaik.

Delos A. said:

I can't get the 13th Age API working properly. Commands like !edie and !setup do nothing afaik.

Do those commands use Sheetworkers? That's the subject of this thread. Just checking, because I'd really like this fixed, and don't want to cloud the waters.

Sheetworker API failure example

API Script: ChatSetAttr

Sheet: Pathfinder by Roll20

Command: !setattr --sel --condition_<any>|<1 or 0> OR !setattr --sel --repeating_buff_<$id>_toggle|<1 or 0>

Expected Behavior:

Actual Behavior:

More Info: Only observable if multiple conditions or multiple buffs are toggled on, whether or not they are specified by the command. Example: Helpless, Paralyzed, and a custom buff are marked as active. If the !setattr command is used to toggle the buff to off, the issue still occurs even though the toggle values for Helpless and Paralyzed were not changed by the command. Other changes to the sheet based on the relevant condition/buff happen normally. This issue doesn't cause any error messages to appear in the API.

Natha said [forum post]:

[...]

This is weird. But it seems like the sheet worker code on the sheet is not behaving as expected when called "from" the API. The characters added between two conditions are a space, a bullet point and another space. So it seems that the character encoding is not properly done when going through API, and then the sheet workers.

[...]

I wonder if this is why the Scum and Villainy sheets started looking odd

It shouldn't be. This thread is about API not triggering sheetworkers. I would think that would be a CSS issue.

Cirolle said:

I wonder if this is why the Scum and Villainy sheets started looking odd

Hi Cassie and Kenton,

I know you folks have been short handed because of conventions and such, but is there an update on this fix? Cassie's first post seemed to indicate this was a minor glitch, though I suspect this turned out not to be the case.

The API script function setWithWorkers doesn't appear to work any more, at all. It sets values, just like set, but never causes any sheet workers based on that state to fire. This should be easy to replicate. You just need any stat, and a sheet worker that changes another stat based on the first stat, then try to use setWithWorker to change first stats value. The second stat value won't change. At least it doesnt for me.

It's very likely there is a race condition somewhere.  A very simple repro character and api script does not seem to exhibit the issue:

<div>
    <div>
        <label for="attr_base">Base Value</label>
        <input type="text" name="attr_base" value="0" title="Base Value" />
    </div>

    <div>
        <label for="attr_derived">Derived Value</label>
        <input type="text" name="attr_derived" value="0" title="Derived Value" />
    </div>
</div>

<div>
    <button type='roll' value="!repro-setwithworker @{character_id}" name="roll_repro">Test</button>
</div>

<script type="text/worker">
    on('change:base',()=>{
        getAttrs(["base"], (attrs)=>{
            setAttrs({
                derived: (attrs.base * 3)
            });
        });
    });
</script>

on('ready',()=>{
	on('chat:message',(msg)=>{
		if('api'===msg.type && /^!repro-setwithworker\b/i.test(msg.content)){
			let args = msg.content.split(/\s+/);
			let c = getObj('character',args[1]);
			if(c){
				let a = findObjs({
					type: 'attribute',
					name: 'base',
					characterid: c.id
				})[0];
				if(a){
					a.setWithWorker({
						current: randomInteger(20)-Math.abs(a.get('current'))
					});
				}
			}
		}
	});
});

After some further testing, I'm pretty certain this is related to the eventinfo based sheet workers.  Here's a repro sheet and script:

<div>
    <div>
        <label for="attr_base">Base Value</label>
        <!-- <input type="text" name="attr_base" value="0" title="Base Value" /> -->
        <input type="number" name="attr_base" step="1" min="0" max="6" value="0" title="Base Value" />
    </div>

    <div>
        <label for="attr_derived">Derived Value</label>
        <input type="text" name="attr_derived" value="0" title="Derived Value" />
    </div>

    <div>
        <label for="attr_base2">Base Value 2</label>
        <!-- <input type="text" name="attr_base2" value="0" title="Base Value" /> -->
        <input type="number" name="attr_base2" step="1" min="0" max="6" value="0" title="Base Value" />
    </div>

    <div>
        <label for="attr_derived2">Derived Value 2</label>
        <input type="text" name="attr_derived2" value="0" title="Derived Value 2" />
    </div>
</div>

<div>
    <button type='roll' value="!repro-setwithworker @{character_id}" name="roll_repro">Test</button>
</div>

<script type="text/worker">
    on('change:base',()=>{
        console.log(`%c[One] Change to attribute: %cbase`,'background-color:#ffcccc;','color:#339933;font-weight:bold;');
        getAttrs(["base"], (attrs)=>{
            setAttrs({
                derived: (attrs.base * 3)
            });
        });
    });

    on("change:base2", function(eventinfo) {

        console.log(`%c[Two] Change to attribute: %cbase2`,'background-color:#ffcccc;','color:#339933;font-weight:bold;');
        console.log(JSON.stringify(eventinfo));
        const newValue = parseInt(eventinfo.newValue) || 0, previousValue = parseInt(eventinfo.previousValue) || 0;
        let update = {
                derived2: `${previousValue} => ${newValue}`
        };
        setAttrs(update, {silent: true});
    });


</script>

on('ready',()=>{
	on('chat:message',(msg)=>{
		if('api'===msg.type && /^!repro-setwithworker\b/i.test(msg.content)){
			let args = msg.content.split(/\s+/);
			let c = getObj('character',args[1]);
			if(c){
				let a = findObjs({
					type: 'attribute',
					name: 'base',
					characterid: c.id
				})[0];
				if(a){
					let newValue = (1+a.get('current'))%7;
					a.setWithWorker({
						current: newValue
					});
					sendChat('Repro',`Set <code>base</code> to <code>${newValue}</code>`);
				}

				let a2 = findObjs({
					type: 'attribute',
					name: 'base2',
					characterid: c.id
				})[0];
				if(a2){
					let newValue = (1+a.get('current'))%7;
					a2.setWithWorker({
						current: newValue
					});
					sendChat('Repro',`Set <code>base2</code> to <code>${newValue}</code>`);
				}
			}
		}
	});
});

I dont think my error was caused by eventinfo based issues, since I wasnt using it. I'll do some more testing.

But I wonder if this 

One other interesting thing I learn in the foray is that a change to a character sheet does not automatically cause a change to the sheetworkers loaded in the API sandbox, which means you should restart your sandbox if you install a new character sheet.  Probably that isn't a major concern for most people, but if you're developing a character sheet and an API script, you'd need to be aware of that.

explains some weirdness I remember seeing when developing a character sheet and an API script in tandem, and finding things not updating properly. 

Just checking on the status of this. It was reported back in May, examples were requested at the beginning of July, and several folks have posted examples along with some detective work. Just wanted to know if any progress has been made. Thanks.

Seconding Keith's request for a status update.

I'm not sure if this is related, but it sounds like it is.

Using DnD 5e character sheet with !spelltracking and !longrest the spell slots on the character sheet aren't affected be either command, however the script appears to properly track everything in the chat.  It only looks like the changes in the script aren't populating to the character sheet.

I don't know anything about scripting, so I can't really pull the specific commands out for help.  Also, to be fair, everything I'm using has been cobbled together from other people's work, so it's not pretty, but it's been largely functional, so I'm not sure if that's it.

Could you post the macro text you are using?

Sorry for the long delay. At this time I have no new updates on the topic. As a sheet author & api writer myself, it continues to be on my mind.

- Cassie

Well, rats. The initial post indicated that the cause was known, so I've been hoping for a simple fix. Thanks for the update, Cassie.

API Script: Modified Inventory Tracker 5e OGL --> https://github.com/Gauzin/ROLL20/blob/master/SheetToChat%20-%2019-08-13.js    (IN PROGRESS, but use !attackShow and click on an item <-- EDITED (had pasted wrong command)

Command that fails:  !toggleEquipment2 -->  hasAttack.setWithWorker({current: this.hasAttack(hasAttack) ? this.HASNOATTACK : this.HASATTACK});

Expected behavior: Upon unchecking and checking with API Script Command, item should automatically get back into the Attacks and Spellcasting section.

Actual behavior: The checkboxes check and uncheck themselves, but upon checking the _hasattack box with the sheetworker, a 'new' attack is not created in said section.

More info: Toggling the box manually in the sheet produces the desired expected behavior. It's just not working via API. I have another thread with maybe a bit more details. --> https://app.roll20.net/forum/post/7678155/5e-ogl-help-setwithworker-on-hasattack-attribute-not-adding-the-item-to-attacks-and-spellcasting-section 

**Thank you Keith for pointing this thread to me ;)

Hope this helps!

Sheetworker API failure example

API Script: ChatSetAttr

Sheet: Pathfinder by Roll20

Command: !setattr --sel --repeating_buff_<$id>_toggle|1

Expected Behavior: 

adjusts to

Actual Behavior: 

adjusts to

More Info:

When the buff toggled on by the API alters the Temp Melee field, the Melee selection in Attack repeating items registers as undefined and so defaults the total attack bonus to +0. It behaves correctly when manually activated, and it doesn't have this effect when the buff alters the Temp Ranged field.

I present the Keith Curtis Incredibly Lame Workaround™ to the following particular issue.

keithcurtis said:

Sheetworker API failure example

API Script: ChatSetAttr

Sheet: D&D5e by Roll20

Command that fails: !setattr --sel --repeating_damagemod_$0_global_damage_active_flag|1

Expected Behavior: Check referenced Global Damage modifier and activate it

Actual Behavior: Checks box, but Global Damage Modifier does not actually activate. You must toggle the box manually for this to happen.

More Info: The inverse of this comand: !setattr --sel --repeating_damagemod_$0_global_damage_active_flag|0 works identically: toggles box off, but does not deactivate modifier. ChatSetAttr has setting to "use sheetworkers"; this has been set to ON. This solution may be related to the D&D5e by Roll20 sheet. Similar steps do work on Shaped sheet for 5e.

keithcurtis said:

I present the Keith Curtis Incredibly Lame Workaround™ to the following particular issue.

No lameness present there. What a hero.

Cheers

Rotimer said:

keithcurtis said:

I present the Keith Curtis Incredibly Lame Workaround™ to the following particular issue.

No lameness present there. What a hero.
Cheers

I polished it up a little bit.

As described in this post the APi Script ChatSetAttr no longer works properly due to sheet workers issue.

https://app.roll20.net/forum/post/7770470/set-attr-api-not-updating-parts-of-the-5e-sheet/?pageforid=7771071#post-7771071

Thanks Anthony!

Cassie and Kenton, most reports on this page reference the D&D5e by Roll20 sheet (One is on the Pathfinder by Roll20 sheet), and even then only some sections. Others appear to work OK. Have these sections been edited to no longer correctly utilize Sheetworkers on attributes set with the API? i.e. is this a sheet problem and not an API problem? This used to work and has been broken a long time. It would be nice to resolve.

Sheetworker API failure example

API Script: ChatSetAttr

Sheet: Pathfinder by Roll20

Command: !setattr --sel --condition_<any>|0

Expected Behavior: The condition attribute is set to zero, the condition is toggled off, it's marker is removed from the sheet, and its penalties to the sheet's attributes are removed.

Actual Behavior: The condition attribute is set to zero, the condition is toggled off, it's marker is NOT removed from the sheet, and its penalties to the sheet's attributes are NOT removed.

I mean, I am no expert, but for a lot of attributes in the html code (if I have it right), it seems that it looks if the event is coming from sheetworker and returns if it is :

on("change:repeating_attack:atkname change:repeating_attack:atkflag change:repeating_attack:atkattr_base change:repeating_attack:atkmod change:repeating_attack:atkmagic change:repeating_attack:atkprofflag change:repeating_attack:dmgflag change:repeating_attack:dmgbase change:repeating_attack:dmgattr change:repeating_attack:dmgmod change:repeating_attack:dmgtype change:repeating_attack:dmg2flag change:repeating_attack:dmg2base change:repeating_attack:dmg2attr change:repeating_attack:dmg2mod change:repeating_attack:dmg2type change:repeating_attack:saveflag change:repeating_attack:savedc change:repeating_attack:saveflat change:repeating_attack:dmgcustcrit change:repeating_attack:dmg2custcrit change:repeating_attack:ammo change:repeating_attack:saveattr change:repeating_attack:atkrange", function(eventinfo) { if(eventinfo.sourceType === "sheetworker") { return; }

In my case posted earlier, I see that it does not trigger the functions to create a new AttackID : 

create_attack_from_item = function(itemid, options) {

const do_update_attack = (attack_array, source) => {

var update_attack_from_item = function(itemid, attackid, options) {

Or some of these functions do not get triggered.

Cassie said:

Greetings folks,

Currently APIs are not triggering sheet workers as they should. The cause of the issue has been identified and I am working on a bug fix now. Unfortunately this will likely not be completed for before the weekend. I apologize for the inconvenience this may cause API users. Rest assured we are working to find a resolution to this issue.

Thank you,

Cassie

Any update on when this will be resolved?

keithcurtis said:

Cassie and Kenton, most reports on this page reference the D&D5e by Roll20 sheet (One is on the Pathfinder by Roll20 sheet), and even then only some sections. Others appear to work OK. Have these sections been edited to no longer correctly utilize Sheetworkers on attributes set with the API? i.e. is this a sheet problem and not an API problem? This used to work and has been broken a long time. It would be nice to resolve.

Just looking for some acknowledgement if not an actual update. This has been broken for a very long time now. Other sections of the D&D5e by Roll20 sheet work properly. Other entire sheets work properly. Can this be fixed?

Greetings Keith,

I looked into this 4 months ago but it was over my head in complexity. The problem is still on our minds. At this time I do not have an ETA on when this will be fixed. 

Thanks,

Cassie

Can the problem be addressed by additional team members? Perhaps someone who wrote the sections of the sheet code that do work? I realize that development has been handed off from developer to developer in the course of the sheet's life, but this is pretty annoying when some parts work and other parts don't with no pattern.

By the way, the setWithWorkers function is not working on the 5e Shaped Sheet either, at least not in the areas I've been trying to use it lately (items in the utility area). I've tried work-arounds but they don't do anything either. It would be great if some more/better attention was given to this issue.

But hey, we all love to open our sheet constantly to click and re-click a toggle or change a value then change it back just so the sheet workers do what they're supposed to do, right? Right!?!

First of all, thank you all for the cases you've provided. They've been invaluable in diagnosing the issue, and planning the steps to repair. In the recent past, we've devoted some time and effort to a fix.

Unfortunately, what's been uncovered is a problem with the infrastructure that runs the API environment. In order to address this problem, we will need to deal with the underlying cause, which is planned to start next month.

Thanks for the update, Kenton. I look forward to the fix!

Thanks for the update!

Is setWithWorker still broken?

Does it work for anyone?

GiGs, here's the deal with the bug in this thread based on my experiences.

Several months ago, when the thread was first made, there was a bug that completely broke the API-sheetworker interaction. This bug was fixed quickly and the API-sheetworker interaction is now working.

The problems that are currently being seen are due to one of two things; 1) code that is deliberately coded so as not to react to the API or 2) code that relies on event.newValue or event.previousValue as there IS a bug with those being passed from API generated events.

Issue 1 is code that has something like the following at the top of it:

if(event.sourceType!=='player'){
    return;
}

This prevents any following code from running unless the event was triggered by a player manually making a change on the sheet. Now obviously, there are some functions where you really do want this behavior. However, many sheets have sheetworkers that are coded this way solely to avoid sheetworker caused changes triggering them; in these cases the logic should be rewritten to specifically screen out sheetworker triggered events instead of all non player triggered events.

Issue 2 is code like this:

on('change:attribute1',(event)=>{
    if(event.newValue*1 > event.previousValue*1){
        //do something
    }
}

The problem here is that API generated sheet events do not have a newValue or previousValue property, so there is nothing to compare here and the function either does nothing or errors out, depending on how it's been coded. There are potentially some other newish event properties that are not passed in an API generated event. You can see exactly what properties are and aren't passed in an API generated event by simply logging the event that is passed and comparing a manual change to an API change.

Pretty much any other sheetworker will properly react to API generated events done with either setWithWorker or the API version of setAttrs (if not passed {silent:true}).