Skip to content
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

Change all functions to return Message and error. #41

Conversation

austinjp
Copy link

@austinjp austinjp commented May 7, 2024

Hi. Many thanks for goqite, it's just what I was looking for 😄

This PR is to enable a workflow I need, where an API can receive a message from a client, add a job into a queue, then return the ID of the job to the client. The client could then (for example) request updates on the progress of that job.

When implementing this, it was necessary to shared the Message and ID structs, so I moved them into the "common" dir.

I had not envisaged so many changes when I started, but the change to function signatures cascaded throughout much of the codebase.

All tests have been updated and all pass, but I'm new to Go so if the code is not idiomatic I'm happy to collaborate on further changes.

This is to enable a workflow I need, where an API can receive a message from a client,
add a job into a queue, then return the ID of the job to the client. This is useful for
allowing the client to request updates on the progress of that job.

When implementing this, it was necessary to shared the Message and ID structs, so I
moved them into the "common" dir.

I had not envisaged so many changes when I started, but the change to function
signatures cascaded throughout much of the codebase.

I'm new to Go, so if this is not idiomatic I'm happy to collaborate on further changes.
@markuswustenberg
Copy link
Member

Hi @austinjp, thank you for wanting to contribute! 😊

I'd like to understand your use case a bit better. Is this with the pure message queue or the new job runner abstraction? Could you describe what you'd like to monitor?

@austinjp
Copy link
Author

austinjp commented May 8, 2024

Hi there. Slight side-track: last night after opening this PR, I noticed your contributor guidelines. As they recommend, I've opened issue #42 to discuss my use case. You're welcome to close this or leave it open as you prefer, until/if the use case makes sense to you!

@austinjp
Copy link
Author

austinjp commented May 8, 2024

Closing this -- it contains a design flaw (a.k.a. bug!) -- the 'common' dir is inside the 'internal' dir, making it inaccessible. See ongoing conversation elsewhere about how this feature might best be implemented.

@austinjp austinjp closed this May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants