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

Fix ScheduleMessage not returning scheduled_message_id #1153

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

hussachai
Copy link
Contributor

I'd like to introduce the fix for ScheduledMessage API. Currently, it doesn't return scheduled_message_id where this ID is needed for cancelling the scheduled message. My change is the least intrusive I could think of. It doesn't introduce any new field or adding new API. Basically, this change should be backward compatible. It is based on the fact that the API chat.postMessage doesn't return scheduled_message_id and the API chat.scheduledMessage doesn't return either message.ts or ts. We just need to check the presence of this field and determine the caller API based on that.

Existing code shouldn't break because the timestamp is always an empty string for ScheduledMessage API.
Now it will return scheduled_message_id in place of timestamp.
SendMessage should remain the same.

Pull Request Guidelines

These are recommendations for pull requests.
They are strictly guidelines to help manage expectations.

PR preparation

Run make pr-prep from the root of the repository to run formatting, linting and tests.

Should this be an issue instead
  • is it a convenience method? (no new functionality, streamlines some use case)
  • exposes a previously private type, const, method, etc.
  • is it application specific (caching, retry logic, rate limiting, etc)
  • is it performance related.
API changes

Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.

  • no tests, if you're adding to the API include at least a single test of the happy case.
  • If you can accomplish your goal without changing the API, then do so.
  • dependency changes. updates are okay. adding/removing need justification.
Examples of API changes that do not meet guidelines:
  • in library cache for users. caches are use case specific.
  • Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.

@TopherGopher
Copy link

This would be amazing to have - there's no way around actually deleting this message.

Copy link

@jvfrodrigues jvfrodrigues left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we get this up?

@lorenzoaiello lorenzoaiello self-assigned this Jul 14, 2024
@winston-stripe
Copy link
Contributor

@hussachai any chance you could fix the merge conflicts that are currently blocking this PR? Would love to see this bug fix merged at some point 😄

@hussachai
Copy link
Contributor Author

@hussachai any chance you could fix the merge conflicts that are currently blocking this PR? Would love to see this bug fix merged at some point 😄

Absolutely! It’s a simple PR. I can’t believe it’s already been about 2 years. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants