I have some state in the saga and trying to implement status check retries until I get some satisfactory value in a message I receved.
Say, I have something like this:
.During(Pending,
When(StatusChecked)
.TransitionTo(somethingThatDependsOnStatusCheckedData)
I can only feed a specific state to TransitionTo but I want it to transition depending on the received message content, is it possible?
For received message content, you can use the conditional expression on the When clause.
During(Pending,
When(StatusChecked, context => context.Data.IsMessageCondition)
.Then(...));
Related
I'm using PgPubsub and I'm trying to get my head around listen and topic*:"" vis-a-vis what to put there.
For example, let's say I have a <PostList> component that renders a list of <Post> and I want to update the list when a Post is created or deleted.
I'm not sure how to structure my subscription so I'm listening for changes to PostList. Here's a screenshot of my GraphiQL:
In pubsub (publish-subscribe), messages are published to a "topic" and you can subscribe to that topic to receive the messages that are published there.
You appear to be using the "simple subscriptions" functionality in PostGraphile, so I'll answer assuming that's the case.
With the subscription listen(topic: "whatGoesHere?") you have, you need to broadcast to the postgraphile:whatGoesHere? topic to trigger a subscription event. You can do this by issuing the SQL statement NOTIFY "postgraphile:whatGoesHere?", '{"ok": true}';. You can do this with psql:
$ psql your_database_here
[your_database_here] # NOTIFY "postgraphile:whatGoesHere?", '{"ok": true}';
NOTIFY
[your_database_here] #
Assuming your GraphQL subscription is running, this should cause the selection set to be evaluated and the results to be sent to GraphiQL.
You'll probably want to fire this NOTIFY statement from a function or trigger; you can read more about that in the PostGraphile Subscriptions documentation.
Problem
Suppose there is a Http request observable that errored, we can just retry it. But I also want the UI to inform the user that this resource failed to load. What is the best architecture?
Intended Behavior for the Target Observable
Retry-able.
Long-running. Doesn't complete or error.
Shared. Does not generate unnecessary requests when multiple subscriber.
Load on need. Does not generate unnecessary requests when not subscribed.
Inform UI of the errors.
(3 and 4 can be achieved by shareReplay({bufferSize: 1, refCount: true}))
My Attempts
I think it's best to pass an error message to the downstream observer while keeping retrying the source. It causes minimum changes to the architecture. But I didn't see a way I can do it with Rxjs, because
retry() always intercepts the error. If you materialze the error, then retry() won't retry. If not, then no error will propagate to the downstream.
catchError() without rethrowing will always complete the stream.
Although let the UI observer tap(,,onError) and retry() can satisfy this need, but I think it is dangerous to let the UI take this responsibility. And multiple UI observer means a LOT of duplicated retries.
Well, I seem to have accidentally find the answer while browsing through the documentations.
It starts with the usage of the second parameter of the catchError. According to the documentation, retry is implemented by catchError. And we can express more logic with the lower-level catchError.
So it's just
catchError((err, caught) => {
return timer(RETRY_DELAY_TIME).pipe(
mergeMap(() => caught)
startWith(err)
);
})
It retries the observable, meanwhile sending error messages to the downstream observers. So the downstream is aware of the connection error, and can expect to receive retried values.
It sounds like you're looking for something akin to an NgRx side effect. You can encase it all in an outer Observable, piping the error handler to the inner Observable (your HTTP call), something like this:
const myObs$ = fromEvent('place event that triggers call here').pipe(
// just one example, you can trigger this as you please
switchMap(() => this.myHttpService.getResource().pipe(
catchError(err => handleAndRethrowError()),
retry(3)
),
shareReplay()
);
This way, if the request throws an error, it is retried 3 times (with error handling in the catchError block, and even if it fully errors out, the outer Observable is still alive. Does that look like it makes sense?
I am investigating using sagas in mass transit to orchestrate activities across several services. The lifetime of the saga is short - less than 2 seconds if all goes well.
For my use case, i would like to use the request/respond approach, whereby the client requests a command, the saga handles that command, goes through some state changes as messages are received and eventually responds to the first command that initiated the saga, at which point the client receives the response and can display the result of the saga.
From what i can see, by this point, the context is no longer aware of the initial request. How can I reply to a message that was received in this way? Is there something i can persist to the saga data when handling the first event, and use that to reply later on?
Thanks Alexey. I have realised that I can store the ResponseAddress and RequestId from the original message on the saga, and then construct a Send() later on.
Getting the response details from the original request
MassTransit.EntityFrameworkIntegration.Saga.EntityFramework
SagaConsumeContext<TSagaData, TMessage> payload;
if (ctx.TryGetPayload(out payload))
{
ResponseAddress = payload.ResponseAddress;
RequestId = payload.RequestId ;
}
Sending the response
var responseEndpoint = await ctx.GetSendEndpoint(responseAddress);
await responseEndpoint.Send(message, c => c.RequestId = requestId);
UPDATE: The documentation has been updated to include a more complete example.
Currently, the saga state machine can only do immediate response like this:
// client
var response = await client.Request(requestMessage);
// saga
During(SomeState,
When(RequestReceived)
.Then(...)
.Respond(c => MakeResponseMessage(c))
.TransitionTo(Whatever)
)
So you can respond when handling a request.
If you want to respond to something you received before, you will have to craft the request/response conversation yourself. I mean that you will have to have decoupled response, so you need to send a message and have a full-blown consumer for the reply message. This will be completely asynchronous business.
In short:
How to proceed listening after an error in stream without putting a .catch before every .subscribe?
If you need more details they are here:
Lets assume I have a Subject of current user or null. I get the data from API sometimes and send to the Subject. It updates the view accordingly.
But at some point error occurs on my server and I want my application to continue working as before but notify some places about the error and KEEP listening to my Subject.
Initially I thought that if I just do userSubject.error(...) it will only trigger .catch callback and error handlers on subscribes and skip all success handlers and chains.
And if after I call userSubject.next(...) all my chains and subscribers will work as before
BUT unluckily it is not the case. After the first uncaught .error it unsubscribes subscribers from the stream and they do not operate any more.
So my question: Why???
And what to do instead if I want to handle null value normally but also handle errors only in some places?
Here is the link to RxJs source code where Subscriber unsubscribes on error
https://github.com/ReactiveX/rxjs/blob/master/src/Subscriber.ts#L140
Rx observables follow the grammar next*(error|complete)?, meaning that they can produce nothing after error or complete notification has been delivered.
An explanation of why this matters can be found from Rx design guidelines:
The single message indicating that an observable sequence has finished ensures that consumers of the observable sequence can deterministically establish that it is safe to perform cleanup operations.
A single failure further ensures that abort semantics can be maintained for operators that work on multiple observable sequences.
In short, if you want your observers to keep listening to the subject after a server error has occurred, do not deliver that error to the subject, but rather handle it in some other way (e.g. use catch, retry or deliver the error to a dedicated subject).
Every Observable emits zero or more next notifications and one error or complete but never both.
For this reason, Subjects have internal state.
Then it depends how you construct your chain. For example you can use retry() to resubscribe to its source Observable on error.
Or when you pass values to your Subject you can send only next notifications and ignore the other two:
.subscribe(v => subject.next(v));
Or if you want to throw error when the user is null you can use any operator that captures exceptions and sends them as error notifications. For example like this:
.map(v => {
if (v === null) {
throw new Error("It's broken");
}
return v;
})
Anyway it's hard to give more precise advice without any code.
I am making a Request from MassTransit state machine saga and wait for reply.
But there could be two errors coming back to me:
MyRequest.TimeoutExpired
MyRequest.Faulted
I don't care on which conditions the request was not fulfilled, I want both situations to result in an error message to be published.
However, I could not find any way to combine two outcomes with or condition, so I can have one handling case for both outcomes and not copy-paste my code.
In this case, you should either create a custom activity (advanced, probably not necessary) or just create a method that is called from both When() conditions, so that you can reuse the behavior between statements.
Task PublishEvent(BehaviorContext<TInstance> context)
{
var consumeContext = context.GetPayload<ConsumeContext>();
return consumeContext.Publish(new MyEvent(...));
}
{
During(MyRequest.Pending,
When(MyRequest.Completed)
.ThenAsync(PublishEvent),
When(MyRequest.Faulted)
.ThenAsync(PublishEvent));
}