If the ISP monetization extension is used inside a hear statement, the skill does not correctly transfer state to the post-monetization flow scenes. Instead, it replays the current scene. You can replicate this by modifying the provided unit tests.
Skill Flow Builder Version
2.1.0
ASK CLI Version
2.22.4
Current Behavior
If you place a buy instruction inside a hear statement, the return scenes specified in the instruction do not activate. If you place a buy statement as the only instruction inside its own scene, everything works as intended.
Alexa > I have two expansions available. The "Fun and Games" expansion and the "Sad and Boring" expansion. To learn more say something like "tell me about the fun and games expansion"
User > Tell me about the fun and games expansion
Alexa > I have two expansions available. The "Fun and Games" expansion and the "Sad and Boring" expansion. To learn more say something like "tell me about the fun and games expansion"
Alexa > [ISP Purchase flow]
User > [Buys expansion]
Alexa > I have two expansions available. The "Fun and Games" expansion and the "Sad and Boring" expansion. To learn more say something like "tell me about the fun and games expansion"
Expected Behavior
buy instructions should correctly handle state changes and errors even if they are called in the context of a hear statement. This is useful for presenting a customer with a menu of items they might want to buy. e.g.
Alexa > I have two expansions available. The "Fun and Games" expansion and the "Sad and Boring" expansion. To learn more say something like "tell me about the fun and games expansion"
User > Tell me about the fun and games expansion
Alexa > [ISP Purchase flow]
User > [Buys expansion]
Alexa > Do you want to try the "Fun and Games" expansion now, or do something else?
Steps to Reproduce
Here's a modification of the isp happy path unit test that replicates the bug
@isp two test
*say
ISP Testing 2 purchases.
*then
-> isp two purchasething
@isp two purchasething
*say
Here comes the first purchase prompt.
*then
buy item='isp two first product' success='isp two bought' declined='isp two declined' fail='isp two nope' already_purchased='isp purchased already' error='isp two error'
@isp two bought
*say
You bought it. Yay!
Here's the second purchase prompt. Say yes to activate.
*then
// THIS STATMENT CAUSES THE ISSUE
hear AMAZON.YesIntent {
buy item='isp two second product' success='isp two lastscene' declined='isp two declined' fail='isp two nope' already_purchased='isp two already' error='isp two error'
}
@isp two nope
*say
Purchase failed.
*then
-> isp lastscene
@isp two declined
*say
You declined it.
*then
-> isp lastscene
@isp two already
*say
You already purchased it.
*then
-> isp lastscene
@isp two error
*say
Error.
*then
-> isp lastscene
@isp lastscene
*say
This is an error scene
*then
>> END
@isp two lastscene
*say
This is the last scene.
*then
>> END
Bug Report
If the ISP monetization extension is used inside a hear statement, the skill does not correctly transfer state to the post-monetization flow scenes. Instead, it replays the current scene. You can replicate this by modifying the provided unit tests.
Skill Flow Builder Version
2.1.0
ASK CLI Version
2.22.4
Current Behavior
If you place a
buy
instruction inside a hear statement, the return scenes specified in the instruction do not activate. If you place abuy
statement as the only instruction inside its own scene, everything works as intended.Expected Behavior
buy
instructions should correctly handle state changes and errors even if they are called in the context of a hear statement. This is useful for presenting a customer with a menu of items they might want to buy. e.g.Steps to Reproduce
Here's a modification of the isp happy path unit test that replicates the bug