Repository navigation
Upgrading to 3.40.0 causing token rotation and installation to fail due to installation.installed_at change. #1832
Description
Reproducible in:
The Slack SDK version
slack_bolt==1.23.0
slack_sdk==3.40.0
Python runtime version
Python 3.12.3
OS info
Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 13 16:40:06 UTC 2026
Steps to reproduce:
- initiate token_rotation or app installation.
Expected result:
Installation data is written to the database
Actual result:
It fails with the following error:
sqlalchemy.exc.DBAPIError: (sqlalchemy.dialects.postgresql.asyncpg.Error) <class 'asyncpg.exceptions.DataError'>: invalid input for query argument $3: datetime.datetime(2026, 2, 13, 23, 57, 0... (can't subtract offset-naive and offset-aware datetimes)
[SQL: SELECT slackbot.slack_installations.id
FROM slackbot.slack_installations
WHERE slackbot.slack_installations.client_id = $1::VARCHAR AND slackbot.slack_installations.enterprise_id IS NULL AND slackbot.slack_installations.team_id = $2::VARCHAR AND slackbot.slack_installations.installed_at = $3::TIMESTAMP WITHOUT TIME ZONE
LIMIT $4::INTEGER]
[parameters: ('2542883913523.8580429677536', 'T02FYRZSVFD', datetime.datetime(2026, 2, 13, 23, 57, 0, 244741, tzinfo=datetime.timezone.utc), 1)]
(Background on this error at: https://sqlalche.me/e/20/dbapi)
If I downgrade to 3.39.0 it works as expected.
The only recent change I see in the SDK related to this is here,
installed_at on line 195 was changed from
now = datetime.utcfromtimestamp(time.time() + self.expiration_seconds)
to
now = datetime.fromtimestamp(time.time() + self.expiration_seconds, tz=timezone.utc)
The former is returns a naive datetime object, whereas the latter returns a timezone-aware datetime object.
The slack_installations table definition for installed_at is:
"installed_at",
DateTime,
nullable=False,
default=sqlalchemy.sql.func.now(),
),
I am using Postgres v16 for my database and the installed_at field is created with the postgres type timestamp -- it is not timezone aware. So the new timezone aware timestamp from the sdk is where the problem occurs. If this is the case then the only solution would be to downgrade to 3.39.0 or update the slack_installation table definition to support the timezone or update the sdk to return a naive datetime object again.
Activity
RubberDuckyToyFactory commentedon Feb 14, 2026
Alternatively, the table definition could be updated to include the timezone=True flag in the constructor; DateTime(timezone=True). This would create the correct table datatype.
WilliamBergamin commentedon Feb 17, 2026
Hi @RubberDuckyToyFactory thanks for bringing this up 💯
Yess #1798 is most like the issue, the table type slipped by our testing 🤔
You suggestion of adding
DateTime(timezone=True)to the construction would be preferred if is does not trigger a breaking change 🤔I'll start working on a PR to resolve this issue
WilliamBergamin commentedon Feb 18, 2026
Thanks again for bring this up 🙏 the issue should be resolved by #1833
Cutting a release for this very soon!
WilliamBergamin commentedon Feb 19, 2026
@RubberDuckyToyFactory thanks again for bring this up 🙏 let us know if the latest release resolved your issue
RubberDuckyToyFactory commentedon Feb 20, 2026
@WilliamBergamin, looks good on my end! I had implemented my own AsyncSQLAlchemyInstallStore, so I used the new
normalize_datetime_for_dbutil and it handles the timezone correctly for the DateTime fields. I've confirmed this on oauth state, app install, and token rotation.Great job! Impressive turn around time, as well. You guys and gals are rocking it!
One other thing... I would have tested this sooner but I had to watch the Canada vs Finland hockey game. GO 🇨🇦! 😉