# Should workflow execute not throw exception when a previous workflow submitted succeeded and the policy is set to 'Allow duplicate failed only'? **URL:** \ **Category:** Community Support\ **Tags:** java-sdk, workflow-options, reuse-policy\ **Created:** [October 6, 2020, 7:20am UTC](https://community.temporal.io/t/should-workflow-execute-not-throw-exception-when-a-previous-workflow-submitted-succeeded-and-the-policy-is-set-to-allow-duplicate-failed-only/702 "2020-10-06T07:20:13Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![madhu](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@madhu](https://community.temporal.io/u/madhu)\ **Post date:** [October 6, 2020, 7:20am UTC](https://community.temporal.io/t/should-workflow-execute-not-throw-exception-when-a-previous-workflow-submitted-succeeded-and-the-policy-is-set-to-allow-duplicate-failed-only/702/1 "2020-10-06T07:20:13Z")
Hi i have a workflow with WORKFLOW\_ID\_REUSE\_POLICY\_ALLOW\_DUPLICATE\_FAILED\_ONLY, first time i submitted a workflow and it went fine, (status completed/success) now second time when i submit another workflow with same name, i happen to create stub and call stub.workflowMethod directly, ( as i want to invoke this workflow synchronously) i get a response immediately, where as i was expected a rejected exception Is my usage in correct or is it a bug? WORKFLOW\_ID\_REUSE\_POLICY\_ALLOW\_DUPLICATE\_FAILED\_ONLY -\> i Interpret this as -\> if workflow failed previously submit one otherwise throw exception/reject (but the behaviour seems to be if workflow ran successfully previously, ignore and do not do anything(no op) ). ---
**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\ **Post date:** [October 6, 2020, 3:08pm UTC](https://community.temporal.io/t/should-workflow-execute-not-throw-exception-when-a-previous-workflow-submitted-succeeded-and-the-policy-is-set-to-allow-duplicate-failed-only/702/2 "2020-10-06T15:08:38Z")
This is by design. If the `id reuse policy` is not `ALLOW_DUPLICATE` then a new synchronous invocation returns the result of the completed workflow each time it is called. What is the use case of receiving the rejection exception instead of the result? ---
**Author:** ![madhu](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@madhu](https://community.temporal.io/u/madhu)\ **Post date:** [October 12, 2020, 7:05am UTC](https://community.temporal.io/t/should-workflow-execute-not-throw-exception-when-a-previous-workflow-submitted-succeeded-and-the-policy-is-set-to-allow-duplicate-failed-only/702/3 "2020-10-12T07:05:13Z")
> [@maxim](#): > > What is the use case of receiving the rejection exception instead of the result? sorry for late response, my use case was more of a resouce creation (simply say domain name ) and i was planning to use this as the workflow id. it self. say some one signup up for a new domain name, if the domain name is not availble workflow gets submitted and the domain is provisioned. if a second person wants the same domain name, i wanted to throw some kind of exception and say the domain name is not available. in stead of returning the previous result (in my case the guy who did the first domain name signup could be totally differnt from the second person). since the workflow id were business ids, i thought of not having any other check and simply submit a second workflow and expected temporal to throw an exception. But as you said, by design it doews not work that way. ---
**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\ **Post date:** [October 12, 2020, 3:19pm UTC](https://community.temporal.io/t/should-workflow-execute-not-throw-exception-when-a-previous-workflow-submitted-succeeded-and-the-policy-is-set-to-allow-duplicate-failed-only/702/4 "2020-10-12T15:19:05Z")
In this case use asynchronous workflow start (using `WorkflowClient.start`) and it is going to throw the rejected exception. Another option is to return some information that can be used to dedupe the user in the workflow result.