DaprStateStore Manual test fails for updated resource names

[lakshmimsft]

Bug information

Dapr test file used in functional tests runs successfully with original resource names but not with changed resource names.
currently investigating this issue ADO task

Steps to reproduce (required)

1. Install latest version of rad. (same behaviour seen in edge & latest released version)

2. run 'rad deploy ' for daprstate.bicep.txt
   this runs successfully.

3. run 'rad deploy ' for daprstate-old.bicep.txt
   this run fails with error
   "code": "Internal",
   "message": "exceeded max retry count to process async operation message: 3"

4. Same behaviour seen when user deletes all resources between runs/ deletes & recreates cluster etc.

Observed behavior (required)

1. There is no difference in first and second bicep file except for names of resources. Hence curious why consistently one runs repeatedly while the other fails.
2. In the failed run:
   redis pod is created and running successfully. container pod is not created.
   application-rp logs indicate deque count increasing for the /CONTAINERS|PUT.. operation type and we see in the queue, the message exists but is not dequeued and is the last remaining message in queue. (attaching sample message)

Attachments:

1. Including module used in bicep files: redis-selfhost.bicep.txt

2. Comparing Input Files:

3. Application-rp log: daprissue-applications-rp-c9485d944-sjncw.log.txt

4. Failed op user sees:

5. Message seen in Queue: queuemessagecntr.txt

Desired behavior (required)

daprstate-old.bicep is deployed successfully, same as daprstate.bicep

Workaround (optional)

System information

rad Version (required)

same behaviour observed on v0.23 and edge

Operating system (required)

macOS Ventura, M1 chip -->

Additional context

currently investigating this issue ADO task

AB#8853

AB#9512

AB#10777

[AaronCrawfis]

The name of the container seems kinda long. Could it be a length issue combined with bad error reporting?

[lakshmimsft]

The name of the container seems kinda long. Could it be a length issue combined with bad error reporting?
Yes, @AaronCrawfis , the daprstate-old.bicep input file deploys successfully when the Application resource name was reduced from a 40 character value to a 25 character value. All other inputs remained the same.
Agreed, 2 areas to work on, as you have mentioned above:

1. identifying constraints/why the length of application resource name was an issue.
2. returning accurate error msg to user.

[lakshmimsft]

Note: This bug was unearthed during split namespace effort and is an existing issue. I will be able to pick it up after Phase 3 of SplitNamespace work. We have currently used shortened app/resource names in tests.

[shalabhms]

@lakshmimsft - please close the issue if there is nothing pending on this work item.

[radius-triage-bot]

👍 We've reviewed this issue and have agreed to add it to our backlog. Please subscribe to this issue for notifications, we'll provide updates when we pick it up.

We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview

[lakshmimsft]

This has to be tested first to check if the issue still exists since it's been a while since this was filed. I'll pick it up next sprint.