Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Service Bus] Support cancellation on $management operations #8159

Merged
merged 9 commits into from
Apr 3, 2020
29 changes: 21 additions & 8 deletions sdk/servicebus/service-bus/review/service-bus.api.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,14 @@

```ts

import { AbortSignalLike } from '@azure/abort-controller';
import { AmqpMessage } from '@azure/core-amqp';
import { delay } from '@azure/core-amqp';
import { Delivery } from 'rhea-promise';
import Long from 'long';
import { MessagingError } from '@azure/core-amqp';
import { OperationOptions } from '@azure/core-auth';
import { RetryOptions } from '@azure/core-amqp';
import { SpanOptions } from '@opentelemetry/types';
import { TokenCredential } from '@azure/core-amqp';
import { TokenType } from '@azure/core-amqp';
import { WebSocketImpl } from 'rhea-promise';
Expand Down Expand Up @@ -82,6 +83,11 @@ export interface MessageHandlers<ReceivedMessageT> {

export { MessagingError }

// @public
export interface OperationOptions extends TracingOptions {
chradek marked this conversation as resolved.
Show resolved Hide resolved
abortSignal?: AbortSignalLike;
}

// @public
export interface ReceiveBatchOptions extends OperationOptions, WaitTimeOptions {
}
Expand Down Expand Up @@ -142,13 +148,13 @@ export interface RuleDescription {

// @public
export interface Sender {
cancelScheduledMessage(sequenceNumber: Long): Promise<void>;
cancelScheduledMessages(sequenceNumbers: Long[]): Promise<void>;
cancelScheduledMessage(sequenceNumber: Long, options?: OperationOptions): Promise<void>;
cancelScheduledMessages(sequenceNumbers: Long[], options?: OperationOptions): Promise<void>;
close(): Promise<void>;
createBatch(options?: CreateBatchOptions): Promise<ServiceBusMessageBatch>;
isClosed: boolean;
scheduleMessage(scheduledEnqueueTimeUtc: Date, message: ServiceBusMessage): Promise<Long>;
scheduleMessages(scheduledEnqueueTimeUtc: Date, messages: ServiceBusMessage[]): Promise<Long[]>;
scheduleMessage(scheduledEnqueueTimeUtc: Date, message: ServiceBusMessage, options?: OperationOptions): Promise<Long>;
scheduleMessages(scheduledEnqueueTimeUtc: Date, messages: ServiceBusMessage[], options?: OperationOptions): Promise<Long[]>;
send(message: ServiceBusMessage): Promise<void>;
sendBatch(messageBatch: ServiceBusMessageBatch): Promise<void>;
}
Expand Down Expand Up @@ -220,11 +226,11 @@ export interface SessionReceiver<ReceivedMessageT extends ReceivedMessage | Rece
peek(maxMessageCount?: number): Promise<ReceivedMessage[]>;
peekBySequenceNumber(fromSequenceNumber: Long, maxMessageCount?: number): Promise<ReceivedMessage[]>;
};
getState(): Promise<any>;
renewSessionLock(): Promise<Date>;
getState(options?: OperationOptions): Promise<any>;
renewSessionLock(options?: OperationOptions): Promise<Date>;
sessionId: string | undefined;
sessionLockedUntilUtc: Date | undefined;
setState(state: any): Promise<void>;
setState(state: any, options?: OperationOptions): Promise<void>;
}

// @public
Expand All @@ -251,6 +257,13 @@ export { TokenCredential }

export { TokenType }

// @public
export interface TracingOptions {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think I've ever noticed how funny this looks.

Also, now it makes me wonder why SpanOptions doesn't contain a field called spanOptions. :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, personally I think I prefer just putting the tracingOptions? field on whatever currently extends TracingOptions, since this only has one field and is now exposed to users when it probably wouldn't be used otherwise. But that's just my opinion 😄

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, @ramya-rao-a 's made this argument in the past and I keep going back and forth on it. I mostly just worry about accidentally making it inconsistent but we can probably counter that by simply having a compile-test like you did recently for core-amqp (I believe)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Any change we want to do here is something I want to ensure is the same between Event Hubs and Service Bus. We already have AMQP and HTTP packages diverging a little, I would prefer to have as much common coding and design patterns between Service Bus and Event Hubs for our own sanity when we move between these 2 projects when in maintainence mode

tracingOptions?: {
spanOptions?: SpanOptions;
};
}

// @public
export interface WaitTimeOptions {
maxWaitTimeSeconds: number;
Expand Down
Loading