Skip to content

Conversation

@gasperzgonec
Copy link
Contributor

Description

This PR changes how the SDK internal logs are printed. As it currently stands, the SDK logs are all prefixed with SDK: .

Connected Issues

Checklist

  • Tests added/updated and ran with npm run test OR no tests needed.
  • Ran backwards compatibility tests with npm run test:backwards-compatibility.
  • no-docs
  • Tested airdrop-template linked to this PR.

@gasperzgonec gasperzgonec marked this pull request as draft September 25, 2025 12:04
@gasperzgonec gasperzgonec marked this pull request as ready for review October 2, 2025 08:04
Copy link
Collaborator

@radovanjorgic radovanjorgic left a comment

Choose a reason for hiding this comment

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

TBH I don't understand this whole complexity behind. So, what we want achieve is just prefixing SDK logs with [SDK] or sth like that, and possibly user logs with [USER]. Most likely I don't understand security issues here, but seems a bit like an overkill to me and sth that can overcomplicate our lifes. Let's discuss this on call.

@gasperzgonec gasperzgonec force-pushed the gasperz/ISS202822 branch 2 times, most recently from 6c7d0fc to 51e57d8 Compare October 9, 2025 13:31
Added SDK prefix ('SDK: ') to all logs coming from the SDK itself.
The class 'sdkconsole' isn't exported and so it shouldn't be possible to
generate it.
It's a convenience class, so that I was able to replace console logs
with minimal changes.
Split the communication into two channels, one for "SDK" and one for the
3rd party user called "USER".
The channel name is written in front of the message (e.g: `[SDK]
Uploading users`).
The SDK needs to do additional steps to use the SDK channel, but 3rd
party users don't.
Copy link
Collaborator

@radovanjorgic radovanjorgic left a comment

Choose a reason for hiding this comment

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

I added few suggestions, will probably add more comments in second review. However, since logger overrides console, can we use console.log/error/warn... at all other places, let's have clear distinction here?

Also, let's ask @navneel99 for quick review after tomorrow's meeting.

export class Logger extends Console {
private options?: WorkerAdapterOptions;
private tags: EventContext & { dev_oid: string };
private isVerifiedChannel: boolean = false; // false = unverified (default), true = verified
Copy link
Collaborator

Choose a reason for hiding this comment

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

isSdkChannel rather than verified?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Renamed


const logObject = {
message,
verified: this.isVerifiedChannel,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we add this to tags variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added

super(process.stdout, process.stderr);
this.options = options;
this.tags = {
...event.payload.event_context,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's add verified here and we rather have something like sdk_log? verified is not self-explainatory in my opinion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've renamed the verified to sdk_log and moved it to tags.

options,
}: SpawnFactoryInterface<ConnectorState>): Promise<void> {
const logger = new Logger({ event, options });
const logger = getInternalLogger(new Logger({ event, options }));
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we rather have factory function for this class (e.g. createLogger(isSdkLogger: boolean)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not entirely sure how to implement that.
createLogger(isSdkLogger: boolean, logger: Logger)
or
createLogger(isSdkLogger: boolean, event: EventContext, options: any)?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Like this?
createLogger(isSdkLogger: boolean, event: AirdropEvent, options: any)

@radovanjorgic radovanjorgic marked this pull request as draft October 20, 2025 08:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants