-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.6.0-rc7 crashing #419
Comments
There is always something that passes through a refactor. |
Ok thanks. I do like the new Request struct layout as I was doing this myself in my own struct. Overall, it's much simpler now. |
After consideration, this will possibly be resolved externally. Here are some thoughts:
Let me know your thoughts. |
Ok, if I add the storage via .data, then I get: Worker missing required context: Missing the an entry for |
I am updating documentation on this.
These are no longer available via |
Let me know if that helps. You can also look at the |
Creating the worker pool: let storage: PostgresStorage<MyReq> = PostgresStorage::new(pool.clone());
let worker = WorkerBuilder::new("MyWorker")
.chain(|srv| srv.layer(TraceLayer::new()))
.backend(storage.clone())
.build_fn(execute); The build_fn like the fn-args example: pub async fn execute(
mut proc: MyReq,
worker_id: Data<WorkerId>,
_worker_ctx: Context<TokioExecutor>,
_sqlite: Data<PostgresStorage<MyReq>>,
task_id: Data<TaskId>,
_ctx: Data<SqlContext>, then I get the crash:
|
You need to do the following: let storage: PostgresStorage<MyReq> = PostgresStorage::new(pool.clone());
let worker = WorkerBuilder::new("MyWorker")
.chain(|srv| srv.layer(TraceLayer::new()))
.data(storage.clone())
.backend(storage.clone())
.build_fn(execute); And for your job fn: pub async fn execute(
mut proc: MyReq,
worker_id: Data<WorkerId>,
_worker_ctx: Context<TokioExecutor>,
_sqlite: Data<PostgresStorage<MyReq>>, //We now include this via data
task_id: TaskId, // TaskId Injected directly
_ctx: SqlContext // Ctx is injected directly
) |
With that setup I get many trait errors like: 72 | .build_fn(execute); 71 | .backend(storage.clone()) |
Well seems I fkd up somewhere. |
Compiles and runs, but now the job gets stuck in the running state. |
Ok interesting. Could you try and pick a test from here, and provide a failing test? |
Is this related to #422 ? My build_fn finishes fine, and I see job.done: DEBUG ThreadId(06) task: apalis::layers::tracing::on_response: job.done done_in=1ms result=OverallResult { ... } but the status does not change to Done (attempt also equals 0 ?)
|
Tower consumes the request as self, so after the job is done, the parts part might need to be refreshed via |
I submit the job and run storage.fetch_by_id to poll the task which is where I'm debugging the context. Even without polling, the DB still has the status as Running:
|
Ack on postgres is chucked and lazy. Can you try sleeping a second or two? |
It doesn't matter if I check or not as I have two modes, sync and async, the sync requests do the polling to check for completion within a timeout period. For async jobs, the tasks are fire and forget essentially. So, even for async jobs, the DB still has them as running even though they did complete. |
This is really interesting. I have integration tests checking this and they
are passing. I will dive more into it and get back to you.
|
@kdesjard I found the bug I was missing a critical implementation in the worker setup. Thanks for highlighting and always trying the latest version. Basically the |
Jobs are finishing now, but I'm getting trait errors if I include the TaskId in the build_fn's args. |
Could you pull the latest from the 0.6 branch and give it a try? There was some other fixes on FromRequest |
All working now, thank you very much. |
After making a number of changes to get 0.6.0-rc7 to compile, I've set the storage backend as always (which includes my request type):
.backend(storage.clone())
But now I get:
Why do I need to use .data now??
The text was updated successfully, but these errors were encountered: