Return ScheduledMessageID everywhere

[mfine]

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

This extends SendMessage* to return scheduled_message_id everywhere. It would be great if the impact of this change could be smaller, but the common SendMessage* functionality is used everywhere so needed to be extended everywhere it was used. If there's a better way to expose scheduled_message_id in a more limited fashion, that would be great.

Fixes #757

[kanata2]

More than 4 or 5 return values for a public function/method is too many,
so we would like to consider some other approach.

[kanata2]

@zchee What do you think?

[pankona]

@kanata2 @zchee
Hello, I'm a one of waiting for release of this patch. I'm afraid to say that I'm happy if you proceed this pull request. Thanks!

[hussachai]

Isn't scheduled message ID applicable to SendScheduledMessage API only? And messageTs is applicable to only SendMessage API. IMO, this change makes it more confusing, and I personally don't like multi-values-return that returns more than 2 values because it's hard to know which one is what without a name. I'd replicate SendMessageContext for scheduled API maybe name it ScheduleMessageContext and returns scheduled message ID in the position of message TS. The better approach would be refactoring the API to reduce the duplication in code which is not much to reduce anyway. Just my 2 cents from the user who is waiting for this.
PS. I have my own a fork version which supports this. My function returns only 2 values instead of 3 like SendMessageContext because I don't know why we need to get a channel ID back when the channel ID is a already known since it is one of function arguments. I don't mind keeping it consistent, but either cases, this will be a breaking change unless we have a new function (the hard part will be naming it :)) and deprecate the old one.

[hussachai]

I proposed the fix for this in the least intrusive way here #1153

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR was closed because it has been stalled for 10 days with no activity.