bolt v4 #2254

filmaj · 2024-09-13T16:20:26Z

Summary

PR (WIP) of what is being discussed as supported for a bolt-js v4 release. Breaking changes are planned for this release!

The tests are failing because of linter and a few other issues, however, #2259 which is intended to be merged into this PR, has all the tests passing. The reason for this split is to make reviewing the major version changes easier on their own in this PR, separate from test utility/linter/reorganization changes.

Open Questions

Should we remove re-exporting of @slack/types? Instead, developers could add a separate dependency on it for their own use. That might be nice, but also it may be nice to re-export the same @slack/types version that is bundled in bolt. Thoughts? Yes let's keep the exports, but try a named export to clearly delineate the types separately from everything else.

Breaking Changes

Middleware Type Changes

This one I'm particularly excited about! In bolt we have a set of Slack*MiddlewareArgs types: for events, shortcuts, commands, and so on. They 'wrap' the underlying event payloads with additional middleware-relevant bits like a next() method, a context object for devs to augment, and so on.

Many of these types, for example the SlackEventMiddlewareArgs type, previously used a conditional to sometimes define particular additional helper utilities on the middleware arguments. For example, the say utility, or tacking on a convenience message property for message-event-related payloads. This was problematic in practice in TypeScript situations, not just internally (this change fixes #2135) within the bolt codebase but for developers as well: when the payload was not of a type that required the extra utility, these properties would be required to exist on the middleware arguments but have a value of undefined. Those of us trying to build generic middleware utilities would have to deal with TS compilation errors and needing to liberally type-cast to avoid these conditional mismatches with undefined.

Instead, these MiddlewareArgs types now conditionally create a type intersection when appropriate in order to provide this conditional-utility-extension mechanism. In practice that looks something like:

type SomeMiddlewareArgs<EventType extends string = string> = {
  // some type in here
} & (EventType extends 'message'
  // If this is a message event, add a `message` property
  ? { message: EventFromType<EventType> }
  : unknown
)

With the above, now when a message payload is wrapped up into middleware arguments, it will contain an appropriate message property, whereas a non-message payload will be intersected with unknown - effectively a type "noop." No more e.g. say: undefined or message: undefined to deal with!

Other Breaking Changes

drops node v14 and v16 (are now EOL'ed)
express to v4->v5; ExpressReceiver users will be exposed to express v4 -> v5 breaking changes
- fixes package vulnerabilities with dependency "path-to-regexp" and "send" #2242
upgrades to @slack/socket-mode v2; SocketModeReceiver users who have attached custom event listeners to the public socketModeClient directly should read the v1 -> v2 migration guide in case the major upgrade could affect them
- fixes Socket mode: Unhandled event 'server explicit disconnect' in state 'connecting' #2225
upgrades @slack/web-api v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes the client within listeners is affected by
removed exported type: KnownKeys
@slack/types now exist under a named export.
removed the SocketModeFunctions class that had a single static method on it and instead directly exposed the defaultProcessEventErrorHandler method from it.
the built-in middleware functions ignoreSelf and directMention now no longer must be invoked as a method in order to return middleware; instead they are middleware to be used directly. this lines up the API for these built-in middlewares to match the other builtins.
AWSReceiver's AwsEvent interface now models event payloads a bit differently; thanks to @seratch's astute review, some additional issues were identified and there's a secondary PR to review for this here: Bolt v4 addendum: stricter typing of AWS API Gateway payloads #2277
- This would resolve Add support for Amazon API Gateway payload format version 2.0 (for HTTP API and Lambda function URLs) #2272
remove deprecated methods/modules/properties:
- OptionsRequest interface
- authed_users and authed_teams from event payload envelope
- render-html-for-install-path module
- verify and VerifyOptions from the verify-request module
- src/receivers/http-utils.ts module

Non-breaking Changes

try some cleanup and a bit of modernization in tsconfig.json
- since we do use fallthrough in switch statements, removed that from tsconfig.json; the alternative of using @ts-ignore comments in places where we do is dangerous, as non-fallthrough-in-switch type errors are also ignored from it
adds a type predicate for asserting a fulfilled vs. rejected promise (for use in array methods like map)
remove some unnecessary type casts in processEvent
dependency updates:
- upgrades raw-body to v3
- upgrades @slack/oauth to v3
- removes promise.allsettled since that is natively supported in node since v14
- moves @types/tsscmp to dev dependencies since that is not exposed to developers

TODO

add deprecations to Steps from Apps things
ci/tests: move to biome, v4 linter fixes #2259 prep a separate lint-passing PR to merge into this PR prior to acceptance (For ease of reviewing the major v4 changes)
Tested with the following samples:
Write a migration guide wiki; work in progress here: https://github.com/slackapi/bolt-js/wiki/Bolt-v3-%E2%80%90--v4-Migration-Guide

Post-release TODO

update all examples and sample dependencies to use bolt v4

codecov · 2024-09-13T16:22:08Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.81%. Comparing base (87d75c5) to head (d58f99f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2254      +/-   ##
==========================================
+ Coverage   87.78%   87.81%   +0.02%     
==========================================
  Files          19       20       +1     
  Lines        1646     1649       +3     
  Branches      464      464              
==========================================
+ Hits         1445     1448       +3     
  Misses        194      194              
  Partials        7        7

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

filmaj · 2024-09-27T18:09:54Z

src/middleware/builtin.ts

- // Filter out any non-actions
- if (action === undefined) {
- return;
+export const onlyActions: Middleware<AnyMiddlewareArgs> = async (args) => {


Breaking change: no longer need to call this as onlyActions(), instead, it is a middleware itself and can be simply passed as onlyActions. The wrapping closure within was unnecessary. This lines it up with other, non-parameterized middleware in this module.

filmaj · 2024-09-27T18:10:30Z

src/middleware/builtin.ts

- if (action === undefined) {
- return;
+export const onlyActions: Middleware<AnyMiddlewareArgs> = async (args) => {
+ if ('action' in args && args.action) {


Instead of casting, in TS we should be using more of 'property' in object style checks and let TS do the type narrowing for us.

filmaj · 2024-09-27T18:11:06Z

src/middleware/builtin.ts

- // Filter out any non-shortcuts
- if (shortcut === undefined) {
- return;
+export const onlyShortcuts: Middleware<AnyMiddlewareArgs> = async (args) => {


Another breaking change: this is a middleware, no need for extra internal closure.

filmaj · 2024-09-27T18:11:20Z

src/middleware/builtin.ts

- // Filter out any non-commands
- if (command === undefined) {
- return;
+export const onlyCommands: Middleware<AnyMiddlewareArgs> = async (args) => {


Same deal! This is middleware, remove internal closure.

filmaj · 2024-09-27T18:11:32Z

src/middleware/builtin.ts

- // Filter out any non-options requests
- if (options === undefined) {
- return;
+export const onlyOptions: Middleware<AnyMiddlewareArgs> = async (args) => {


Broken record: middleware, remove internal closure.

filmaj · 2024-09-27T18:11:49Z

src/middleware/builtin.ts

- // Filter out any non-events
- if (event === undefined) {
- return;
+export const onlyEvents: Middleware<AnyMiddlewareArgs> = async (args) => {


You guessed it: middleware, 🔪 closure

filmaj · 2024-09-27T18:11:57Z

src/middleware/builtin.ts

- // Filter out anything that doesn't have a view
- if (view === undefined) {
- return;
+export const onlyViewActions: Middleware<AnyMiddlewareArgs> = async (args) => {


💡 🧠 Big fan of it all!

filmaj · 2024-09-27T18:12:44Z

src/middleware/builtin.ts

- return;
- }
- }
+export const ignoreSelf: Middleware<AnyMiddlewareArgs> = async (args) => {


Same: 🔪 internal closure since we don't use any of the outer function's parameters.

filmaj · 2024-09-27T18:13:15Z

src/middleware/builtin.ts

+ if (isMessageEventArgs(args)) {
+ const { message } = args;
+ // Look for an event that is identified as a bot message from the same bot ID as this app, and return to skip
+ if (message.subtype === 'bot_message' && message.bot_id === botId) {


The combination of cleaning up the middleware types and use of type predicates lets us clean up the type casting and simplify the logic in this method ❤️

filmaj · 2024-09-27T18:13:59Z

src/middleware/builtin.ts

- | GlobalShortcut
- | InteractiveMessageSuggestion
- | DialogSuggestion;
+export const directMention: Middleware<SlackEventMiddlewareArgs<'message'>> = async ({ message, context, next }) => {


🔪 closure, straight middleware

filmaj · 2024-09-27T18:14:28Z

src/receivers/AwsLambdaReceiver.ts

@@ -10,15 +10,15 @@ import { StringIndexed } from '../types/helpers';

 export interface AwsEvent {
 body: string | null;
- headers: any;
+ headers: Record<string, string>;


Breaking change: HTTP request headers are string:string maps

Let's follow this type def: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/trigger/api-gateway-proxy.d.ts It seems the value in the data can be undefined

Resolving #2272 as well is a plus

I looked at this more closely. Here is my assessment - let me know if you agree / if I should proceed / how to adjust:

The v1 payload definition is here and it looks like:
{ // Shared properties with v2: body: string | null; headers: APIGatewayProxyEventHeaders; isBase64Encoded: boolean; pathParameters: APIGatewayProxyEventPathParameters | null; queryStringParameters: APIGatewayProxyEventQueryStringParameters | null; requestContext: APIGatewayEventRequestContextWithAuthorizer<TAuthorizerContext>; stageVariables: APIGatewayProxyEventStageVariables | null; // v1 only properties: multiValueHeaders: APIGatewayProxyEventMultiValueHeaders; httpMethod: string; path: string; multiValueQueryStringParameters: APIGatewayProxyEventMultiValueQueryStringParameters | null; resource: string; }

The v2 payload definition is here and it looks like:
{ // Shared properties with v1: body?: string; headers: APIGatewayProxyEventHeaders; isBase64Encoded: boolean; pathParameters?: APIGatewayProxyEventPathParameters; queryStringParameters?: APIGatewayProxyEventQueryStringParameters; requestContext: TRequestContext; stageVariables?: APIGatewayProxyEventStageVariables; // v2 only properties: version: string; routeKey: string; rawPath: string; rawQueryString: string; cookies?: string[]; }

I took a pass at typing this as a union of V1Payload | V2Payload - as you suggested, see the compare view with this branch here - but because of the incompatible types for some of the same properties (e.g. body is string | null in v1 but string | undefined in v2) it may lead to TypeScript compilation problems in userland code, depending on how userland code uses these properties. May be problematic, not sure, though it shouldn't be difficult; it should be as simple as using the following in user code:

if ('version' in payload) { // payload is now v2 } else { // payload is now v1 }

You can also see in the compare view that it does require even minor modifications to the receiver code; that is, references to awsEvent.path need to be narrowed first into either v1 (where path is available) or v2 (where instead rawPath should be used). I think this is actually safer code: it correctly and explicitly deals with either payload more appropriately, in my opinion. So I am in favour of this change, but, what do you think @seratch ? If we agree on this change, I would definitely add a section to the migration guide to cover this change and document users how to migrate their code in case they do need to touch the AwsEvent interface. I think this could affect userland code if users define their own customPropertiesExtractor or invalidSignatureHandler methods, since those methods are passed an AwsEvent argument.

I've created a draft PR into this PR to be able to more specifically discuss this one change here: #2277

Thanks for quickly resolving this! Yes, I agree that this type of change is fine when we release a new major version.

filmaj · 2024-09-27T18:14:47Z

src/receivers/AwsLambdaReceiver.ts

- queryStringParameters: any | null;
- multiValueQueryStringParameters: any | null;
- stageVariables: any | null;
+ pathParameters: any;


any already includes null, so can clean this up.

filmaj · 2024-09-27T18:14:59Z

src/receivers/AwsLambdaReceiver.ts

- multiValueQueryStringParameters: any | null;
- stageVariables: any | null;
+ pathParameters: any;
+ queryStringParameters: Record<string, string>;


Same as headers, query string parameters are string:string maps.

filmaj · 2024-09-27T18:15:28Z

src/receivers/ExpressReceiver.spec.ts

@@ -529,7 +529,7 @@ describe('ExpressReceiver', function () {
 // Act
 const req = { body: { }, url: 'http://localhost/slack/oauth_redirect', method: 'GET' } as Request;
 const resp = { send: () => { } } as Response;
- (receiver.router as any).handle(req, resp);
+ (receiver.router as any).handle(req, resp, () => {});


A change that was required as part of the move from express v4 -> v5

seratch

Great work; Left a few comments!

seratch · 2024-09-27T23:58:42Z

src/receivers/AwsLambdaReceiver.ts

@@ -10,15 +10,15 @@ import { StringIndexed } from '../types/helpers';

 export interface AwsEvent {
 body: string | null;
- headers: any;
+ headers: Record<string, string>;


Let's follow this type def: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/trigger/api-gateway-proxy.d.ts It seems the value in the data can be undefined

seratch · 2024-09-27T23:59:16Z

src/receivers/AwsLambdaReceiver.ts

- multiValueQueryStringParameters: any | null;
- stageVariables: any | null;
+ pathParameters: any;
+ queryStringParameters: Record<string, string>;


According to https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/trigger/api-gateway-proxy.d.ts, this can be either object or null

Great call to follow that project; what if we used it as a dependency instead of maintaining our own types?

Indeed it's worth considering. Perhaps as an optional dependency (like we plan for express)?

seratch · 2024-09-27T23:59:48Z

src/receivers/AwsLambdaReceiver.ts

@@ -10,15 +10,15 @@ import { StringIndexed } from '../types/helpers';

 export interface AwsEvent {
 body: string | null;
- headers: any;
+ headers: Record<string, string>;


Resolving #2272 as well is a plus

seratch · 2024-09-28T00:02:18Z

tsconfig.json

@@ -1,25 +1,17 @@
 {


I haven't checked this is backward-compatible yet, but running npm pack with both old and new settings and verifying the diff (or any technique like that) would be worth doing (you might have already done this tho!)

I did add example integration tests in the test PR (see here); the application TypeScript seems to compile fine when integrated with this PR.

I will do a manual testing pass with the other well-known sample bolt-js apps we have to validate everything works as desired. I don't think the emitted JavaScript should be different, since it is still set to emit commonjs (just like before) and module resolution is still node (just like before), but I will validate manually. And if there are any other sample applications we should integrate with, let me know and I can add it to the CI (at least compilation-level validation with TypeScript projects is an easy integration test to run).

Tested works fine with the following samples:

https://github.com/slack-samples/bolt-js-custom-step-template

https://github.com/slack-samples/bolt-js-starter-template

https://github.com/slack-samples/bolt-ts-custom-function-template

https://github.com/slack-samples/bolt-ts-starter-template

Thanks for double-checking this! 🙇

…rsions

…ments. fix up getting started typescript example

…ore. the ts-ignore comment is worse than using fallthrough.

… type assertions.

…d_teams) from event payload envelope interface

…e invoked as a method to return middleware; instead, they are directly middleware, like other built-in middleware functions.

…e `message` parameter. THIS FIXES SO MUCH! shouts to jcalz on stackoverflow

…ntMiddlewareArgs when event contains channel information.

…ionMiddlewareArgs when a non-dialog or step from app action

…rtcutMiddlewareArgs when a non-dialog or step from app action. also TODOs

… flat map of strings to strings

…inder removal todos for eventual removal

zimeg

Awesome and wonderful changes all throughout! I tested this with some other apps and am finding things build well 🙏 ✨

Most comments I left might be noise and excitement, but I did leave a few thoughts on the @slack/types export that I'm open to discussing more! 🚀

I'll also continue to test, but am noticing something strange happening with @slack/socket-mode and incoming events - going to open a separate issue for this though 👀

From the look of things, the migration guide is also looking to be a smooth process too - super nice 👏 👏

.github/workflows/ci-build.yml

zimeg · 2024-10-02T06:37:12Z

src/middleware/builtin.ts

- // Filter out anything that doesn't have a view
- if (view === undefined) {
- return;
+export const onlyViewActions: Middleware<AnyMiddlewareArgs> = async (args) => {


💡 🧠 Big fan of it all!

src/middleware/builtin.ts

src/types/actions/index.ts

zimeg · 2024-10-02T07:15:09Z

examples/getting-started-typescript/src/basic.ts

@@ -119,7 +119,7 @@ app.action<BlockAction>({ action_id: 'select_user', block_id: 'assign_ticket' },
 await client.reactions.add({
 name: 'white_check_mark',
 timestamp: body.message?.ts,
- channel: body.channel?.id,
+ channel: body.channel!.id, // if the body has a message, we know it has a channel, too.


Could adding body.channel to the if above remove this check and ?

zimeg · 2024-10-02T07:43:08Z

src/types/events/index.ts

@@ -2,21 +2,24 @@ import { SlackEvent } from '@slack/types';
 import { StringIndexed } from '../helpers';
 import { SayFn } from '../utilities';

-// TODO: for backwards compatibility; remove at next major (breaking change)
-export * from '@slack/types';


Should we remove re-exporting of @slack/types? Instead, developers could add a separate dependency on it for their own use. That might be nice, but also it may be nice to re-export the same @slack/types version that is bundled in bolt.

🤔 Hmmmm... I'm thinking it makes sense to keep the export to avoid possible version drifts between the latest of each package, though this might not be a concern between minor or patch bumps?

We might also need to remove this from src/index.ts too, but I'm super curious what you think about a named export instead?

export * as types from '@slack/types';

This could make working with Block Kit more clear IMO when using typeahead to find the blocks or similar types of exploration 🔍

import bolt from "@slack/bolt"; const header: bolt.types.HeaderBlock = { type: "header", text: { type: "plain_text", text: "Greetings traveler!", }, };

Sounds good re: keeping the types export. On this topic, now that I think about it, we actually do a similar thing in deno-slack-sdk: it includes the deno-slack-api project, and initially we kept them separate and had users import both. This turns out to be a pain for developers, and I regret that decision. So, let's keep the types export.

And I like your idea to do a named export; will play around with that.

src/types/helpers.ts

zimeg · 2024-10-02T07:48:49Z

src/types/utilities.ts

+/** Using type parameter T (generic), can distribute the Omit over a union set. */
+type DistributiveOmit<T, K extends PropertyKey> = T extends any
+ ? Omit<T, K>
+ : never;


This might be nice to include with the src/types/helpers.ts 🐙 But no blocker!

zimeg · 2024-10-02T07:50:50Z

package.json

- "@types/express": "^4.16.1",
- "@types/promise.allsettled": "^1.0.3",
- "@types/tsscmp": "^1.0.0",
+ "@slack/web-api": "^7",


This is huge!! 🙏 ✨ 🚀

filmaj added semver:major draft A pull request that is currently in active development and not yet ready for review labels Sep 13, 2024

filmaj added this to the 4.0.0 milestone Sep 13, 2024

filmaj self-assigned this Sep 13, 2024

filmaj mentioned this pull request Sep 13, 2024

Fix #2242 by upgrading express and its dependencies to newer major versions #2244

Closed

2 tasks

filmaj mentioned this pull request Sep 15, 2024

ci/tests: move to biome, v4 linter fixes #2259

Draft

1 task

This was referenced Sep 23, 2024

release candidate: pull in socket-mode RC to test stability improvements #2095

Closed

bug: buildSource does not take into account authorizations array when sourcing user_id during user-token retrieval/authorization #2271

Open

filmaj force-pushed the bolt-four branch from 249a3bc to e0988da Compare September 27, 2024 17:46

filmaj marked this pull request as ready for review September 27, 2024 17:50

filmaj changed the title ~~v4 draft~~ bolt v4 Sep 27, 2024

filmaj removed the draft A pull request that is currently in active development and not yet ready for review label Sep 27, 2024

filmaj commented Sep 27, 2024

View reviewed changes

filmaj requested a review from a team September 27, 2024 18:18

seratch reviewed Sep 28, 2024

View reviewed changes

Fix #2242 by upgrading express and its dependencies to newer major ve…

f2ac280

…rsions

filmaj added 24 commits October 1, 2024 09:27

add test for say() utility w/ blocks - should not error

4b18b4a

add distributiveomit utility type and use it for say and respond argu…

fb54885

…ments. fix up getting started typescript example

removed exported but unused KnownKeys

87aadc1

more todos, tweaking message type tests

ea38453

get rid of a type cast in processEvent

d458b6c

tsconfig: allow fallthrough in cases in switch, remove related ts-ign…

1106888

…ore. the ts-ignore comment is worse than using fallthrough.

TODO

59a8a61

TODOs

dcfe247

TODOs and improving the message handler type tests with more specific…

14f091d

… type assertions.

removing inapplicable TODO

1a37965

TODO and issue link

8b60ae4

remove deprecated OptionsRequest interface

1ac5531

breaking change: do not re-export slack/types

c71ee1a

breaking change: remove two deprecated properties (authed_users authe…

53faf52

…d_teams) from event payload envelope interface

breaking change: delete deprecated render-html-for-install-path module

13b388f

breaking change: remove deprecated verify method

4c178aa

breaking change: remove deprecated http-utils module.

ee6f660

breaking change: ignoreSelf and directMention now no longer need to b…

cff0f93

…e invoked as a method to return middleware; instead, they are directly middleware, like other built-in middleware functions.

redo how the SlackEventMiddlewareArgs type conditionally exposes th…

68d1f6a

…e `message` parameter. THIS FIXES SO MUCH! shouts to jcalz on stackoverflow

use conditional typing w/ unknown to add a say property to SlackEve…

f2660fe

…ntMiddlewareArgs when event contains channel information.

use conditional typing w/ unknown to add a say property to SlackAct…

81d9bea

…ionMiddlewareArgs when a non-dialog or step from app action

use conditional typing w/ unknown to add a say property to SlackSho…

8bb38ba

…rtcutMiddlewareArgs when a non-dialog or step from app action. also TODOs

awsEvent breaking change: header and querystrings can be modeled as a…

b433f29

… flat map of strings to strings

adding deprecation notices to Steps from Apps stuff, and dropping rem…

50c9fd0

…inder removal todos for eventual removal

filmaj force-pushed the bolt-four branch from e0988da to 50c9fd0 Compare October 1, 2024 13:27

This was referenced Oct 1, 2024

Add support for Amazon API Gateway payload format version 2.0 (for HTTP API and Lambda function URLs) #2272

Open

Bolt v4 addendum: stricter typing of AWS API Gateway payloads #2277

Merged

zimeg reviewed Oct 2, 2024

View reviewed changes

zimeg mentioned this pull request Oct 2, 2024

Parsing incoming WebSocket message fails with a SyntaxError from invalid JSON slackapi/node-slack-sdk#2057

Open

1 task

Bolt v4 addendum: stricter typing of AWS API Gateway payloads (#2277)

4820052

bolt v4 #2254

Are you sure you want to change the base?

bolt v4 #2254

Conversation

filmaj commented Sep 13, 2024 • edited Loading

Summary

Open Questions

Breaking Changes

Middleware Type Changes

Other Breaking Changes

Non-breaking Changes

TODO

Post-release TODO

codecov bot commented Sep 13, 2024

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seratch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zimeg left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

filmaj commented Sep 13, 2024 •

edited

Loading

zimeg left a comment •

edited

Loading