Removed the extra space in expected test result

[Arashrohani]

Signed-off-by: Arash Rohani Arash.Rohani@gmail.com

Description

Removed the extra space in expected test result to fix the test workflow.

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• The quickstart code compiles correctly
• You've tested new builds of the quickstart if you changed quickstart code
• You've updated the quickstart's README if necessary
• If you have changed the steps for a quickstart be sure that you have updated the automated validation accordingly. All of our quickstarts have annotations that allow them to be executed automatically as code. For more information see mechanical-markdown. For user guide with examples see Examples.

[msfussell]

LGTM. To get the test passing

[paulyuk]

LGTM, works in my local kubernetes. Let's try it in the action now. Thank you for the contribution @Arashrohani

[paulyuk]

LGTM, works in my local kubernetes. Let's try it in the action now. Thank you for the contribution @Arashrohani

[Arashrohani]

Hi @paulyuk Thanks Paul, it seems that the order of messages is different sometimes, would you please re-run the workflow or do you have any suggestions on how to fix the order issue?

[paulyuk]

Hi @paulyuk Thanks Paul, it seems that the order of messages is different sometimes, would you please re-run the workflow or do you have any suggestions on how to fix the order issue?

Hey @Arashrohani - I can rerun it easily but I dont have a good suggestion for now how we can deal with the async nature of it.

I'm noticing one other thing that may be a problem in the C# test-- see how this shows info: Program[0] in the stout? I have a theory that is causing the markdown test to think it wasn't output even though we see it here. Could you please change the C# code and readme to use Console.Writeline( ) instead of Logger.LogInformation in all cases?
== APP == info: Program[0]
== APP == B: Message on B
== APP == info: Program[0]
== APP == C: Message on C
== APP == info: Program[0]
== APP == A: Message on A
ℹ️
terminated signal received: shutting down
✅ Exited Dapr successfully
✅ Exited App successfully
ERROR expected lines not found:
== APP == B: Message on B
== APP == C: Message on C
Exited Dapr successfully
Exited App successfully

Here is a reference to the failure I see still: https://github.com/dapr/quickstarts/runs/6779030966?check_suite_focus=true#step:19:334

One more thing do you happen to be on Discord or some other way to faster chat as we figure this out?

[Arashrohani]

@paulyuk You think that would fix the issue regarding the order? Can we add delay between sending the sample messages to fix the order issue because the code is working, the problem is that the test runner is looking for those messages in order? if you want me to replace those calls with Console.Writeline() I would do it, Unfortunately I don't use discord :(

[Arashrohani]

@paulyuk Replaced it with Console.WriteLine but it didn't fix the order issue (it broke the first test also but I think that is related to whitespaces), I think the best approach is to add a delay or update the test runner or we can just keep one of those messages in the step (I don't like this)

[paulyuk]

@paulyuk Replaced it with Console.WriteLine but it didn't fix the order issue (it broke the first test also but I think that is related to whitespaces), I think the best approach is to add a delay or update the test runner or we can just keep one of those messages in the step (I don't like this)

Ok do you want to try the delay? The test runner update might be impactful and more than we bargained for -- for now.

[Arashrohani]

Hey @paulyuk Hmm, Sure, where should I update that? in readme? I though that is going to be somewhere else?! Do you want me to change it back to use logger?

[paulyuk]

Hey @paulyuk Hmm, Sure, where should I update that? in readme? I though that is going to be somewhere else?! Do you want me to change it back to use logger?

Yes I suggest we add a sleep to the readme to the mechanical markdown that the user won't see.

Looks like there is a sleep directive: https://github.com/dapr/mechanical-markdown/blob/main/examples/background.md#sleeping

[paulyuk]

Given there is a bit of a race and timing condition here, I suggest we put in a sleep to give each message more time to process and validate in order.

[Arashrohani]

@paulyuk I just noticed that the first csharp subscriber step already has the sleep on it but I have seen that sometimes is failing because of order, I think we should put sleep in places that we are sending the messages for each step?
Are those steps in the Readme also? is this one of them?

<!-- STEP
name: Curl validation k8s

After I got your confirmation I would apply the change and change the messages to use logger again and push it up.

[paulyuk]

Yes I believe we should expand on sleeps to make it as deterministic as possible. Perhaps we really increase sleeps like to 5 seconds to ensure?

[paulyuk]

also agree it might be bette rto try where we're sending the messages. Those all come from the same process and might be more deterministic.

[Arashrohani]

@paulyuk Sounds good, so Should I just revert the Console to logger and push it up or do I need to add sleep for steps also?

[paulyuk]

Hey. I could be ok either way. What's your preference ? My only thought is most other quickstarts use console

[Arashrohani]

Hey @paulyuk I prefer consistency, I fixed the whitespace issue after adding the Console and added sleep directive to C# subscriber step only. Please let me know what else I need to do?

[paulyuk]

Ok I like the choice you made. Does it pass well and "look good to you now"? I will also test.

[Arashrohani]

It seems that it does, and I think it looks good, thanks for asking me :)

[paulyuk]

Awesome. I will carve out some time to give it a test and final look, today hopefully.

Thank you so much for driving this. Improving test stability has a lot of positive impact on the project.

[paulyuk]

LGTM!

[msfussell]

@Arashrohani - Really appreciate this contribution and finding this issue!