Home Community Blog Buy Now
Blog

Misty Community Forum

[Resolved] Issues with `Set` and `Get` after 2020.04.07 System Update

Hello, since the last update, my skill does not work anymore. It seems that the misty.Get command can’t get the data.

“Failed to get data using key ‘endormi’ and skill namespace ‘9681a952-e1be-4d40-81d9-141fe923cf91’” “2020-04-09T18:03:30.5484566Z”
skillrunner.js:515 null
skillrunner.js:511 “Failed to get data using key ‘afficheRonflement’ and skill namespace ‘9681a952-e1be-4d40-81d9-141fe923cf91’” “2020-04-09T18:03:30.5640824Z”
skillrunner.js:515 null
skillrunner.js:511 “Failed to get data using key ‘findFace’ and skill namespace ‘9681a952-e1be-4d40-81d9-141fe923cf91’” “2020-04-09T18:03:30.6893422Z”
skillrunner.js:515 null
skillrunner.js:511 “Failed to get data using key ‘Ecoute’ and skill namespace ‘9681a952-e1be-4d40-81d9-141fe923cf91’” “2020-04-09T18:03:30.6893422Z”
skillrunner.js:515 null
skillrunner.js:511 “Failed to get data using key ‘endormi’ and skill namespace ‘9681a952-e1be-4d40-81d9-141fe923cf91’” “2020-04-09T18:03:33.569768Z”
skillrunner.js:515 null

Is it due to change made on case-sensitive in this update.

Thanks if you know how to fix that.

Hi @qriolab,

Thanks for sharing this here. We’ve been tracking this internally, too; we saw something similar in a few skills on robots running the 2020.04.07 release yesterday.

From what I understand, we found two issues associated with reading & writing shared skill data in this release:

a) The first issue is related to a mixup in the location where skill data is stored when there is no value assigned to the SkillStorageLifetime attribute in your JSON meta file. It sounds like something unexpected happens when that attribute doesn’t exist, and skill data isn’t being written to/read from the right location.
b) The second issue has to do with disabled thread locking causing race conditions wherein separate threads are attempting to read/write the same value at the same time. If your skill calls on misty.Set to write to the same value several times in quick succession, this could be the cause of the behavior reported above.

We have fixes in development to prevent this race condition, and to make sure skills always read/write shared skill data from the right location. We’re testing these fixes for Misty’s next release. I expect this to be resolved in the next system update without requiring updates to your skill code.

In the meantime, I’m told there may be a workaround for issue a) above, although it has not been tested, and it would require you to update your skill code in ways that won’t be required when the fix is released. (In other words, if you try this, consider it an experiment; I can’t guarantee that it will resolve your issue.) To try it, make sure the JSON meta file for your skill includes a SkillStorageLifetime attribute with a value of LongTerm:

"SkillStorageLifetime": "LongTerm"

Then, update your code to change the third argument in each of your calls on the misty.Set() method to true. This argument toggles longTermStorage for that particular piece of data. Setting this argument to true for all of the data your skill writes – and using LongTerm in your meta file – should indicate that all of the skill’s data belongs in long term storage, avoiding the mixup caused by the bug in the default behavior.

Thanks Johnathan for the explanation. Unfortunately the workaround does not work, I will have to wait the next update.
Is the “SET” and “GET” the only way to share data between functions in the same skill? I try declaring the variable with VAR but does not work. I also try the _ (underscore) before the name of the variable.

Thanks for the update, @qriolab.

Using _<varName> allows the value to be validly updated across threads within the same skill, but you are correct in that these variable can’t be shared across skills.

I’m not sure what your use case is, but you might look into using the misty.TriggerEvent method. This method lets you create user events with custom data payloads, and you can create listeners for these events to trigger callback functions in any other skills that are running on your robot.

I should also mention that if you are open to using Misty’s .NET SDK, you can create your own database for sharing data across skills, as discussed in this thread.

Thanks Johnathan, I appreciate your support.

Best regards,

Hi @qriolab,

We just released an update that resolves this issue. Your robot should receive this update soon (if it hasn’t updated already). Learn more in the release notes: 2020.04.21 System Update