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.
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 returnscheduled_message_id
and the API chat.scheduledMessage doesn't return eithermessage.ts
orts
. 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 forScheduledMessage
API. Now it will returnscheduled_message_id
in place oftimestamp
.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
API changes
Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.
Examples of API changes that do not meet guidelines: