Delegate directives from LaunchRequest should be able to come back to the skill as IntentRequests

shadoof commented 4 years ago

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Expected Behavior

When addDelegateDirective(updatedIntent) from a LaunchRequest, if Auto Delegation is disabled for the skill? for LaunchRequests? for the updatedIntent? (however it should be done), then behave as for the same situation when the delegating request is an IntentRequest: giving in-code control over the dialog prompts to the developer. This is important for localization, since otherwise localized strings have to be provided in the Interaction Model for all locations. Maybe this would be an issue for Alexa Conversations also?

Current Behavior

Unless I'm mistaken, because input etc. is final, any addDelegateDirective() from a LaunchRequest can only ever be handled by Auto Delegation, whereas when delegating from an IntentRequest, by disabling auto delegation I have control of, for example, a confirmation prompt from within my code (see above).

Steps to Reproduce (for bugs)

// Provide a self-contained, concise snippet of code
// For more complex issues provide a repo with the smallest sample that reproduces the bug
// Including business logic or unrelated code makes diagnosis more difficult

        if (input.matches(requestType(LaunchRequest.class))) {
            // *** what we'd like to do
            // with Auto Delegation disabled 
            // but ? we can't change
            // the requestType of any input even for a dialog ***

             if ("ask".equals(WILL)) {
                Intent launchAsk = Intent.builder()
                    .withName("LaunchAskIntent")
                    .build();
                return input.getResponseBuilder()
                    .addDelegateDirective(launchAsk)
                    .withSpeech("delegating to: LaunchAskIntent")
                    .build();
             }
            return new LsnrsLaunchResponse(input).getResponse();
        }
        else {
            // delegated LaunchAskIntent handled here 'next turn'
        }

Possible Solution

// Not required, but suggest a fix/reason for the bug,
// or ideas how to implement the addition or change

Context

In some situations (e.g. after the user 'hard' exits from the skill) I want to ask, on launch, if any persistent attributes should be retrieved or not. This would be a common enough use case. In the live skill that I am re-engineering with simple persistence, https://github.com/shadoof/thelisteners, I will, currently, workaround by letting the Auto Delegation take place and putting localized prompt variants in my model.

Your Environment

ASK Java SDK version used: x.x.x
Operating System and version: ask-sdk 2.5.5 AWS Lambda hosted MacOS 10.14.6 Mojave

Java Info

Java version used for development: Java 8 java version "1.8.0_181"

shadoof commented 4 years ago

I just bumped my version of the ask-sdk to 2.30.1 and this is still an issue based on tests I've done.

nikhilym commented 3 years ago

Hey @shadoof , sorry for the late response. This seems to be a feature request for change of behavior in dialog management for alexa requests and is not related to the SDK itself. Can you please add this in our UserVoice forums so that the concerned team managing the service is involved?

Please let us know if there is any other issue. Thanks.

shadoof commented 3 years ago

I have posted an 'awaiting moderation' feature request where you suggested, thanks @nikhilym with the subject: 'Treat delegate directives from launch requests the same as from intent requests'. I guess will close this but I hope everyone with vote up my request ;)

alexa / alexa-skills-kit-sdk-for-java