Native Cluster failover tears down a topic's server-side proxy session
on the surviving nodes without notifying the client -- the SDK's local
_attached flag is never reset on this path, so isSubscribed()/
ensureTopicAttached() keep reading a stale true and can't catch it in
advance. The server replies 409 "must attach first" to the {pub}
itself; publishWithReattach() catches exactly that, forces a fresh
subscribe(), and retries the same msg object once (safe: publishDraft's
own _noForwarding guard prevents a duplicate local echo, and the
unchanged x-im-client-mid still dedupes server-side). Wired into all 9
publishDraft call sites (send.ts, attachments.ts, calls.ts).
Confirmed live on an independent native-Cluster verification
deployment: killing the leader pod mid-conversation previously caused
every send to fail until a manual resubscribe; with this fix, 36/36
probes across the same failover succeeded with no manual intervention.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
91 lines
4.2 KiB
TypeScript
91 lines
4.2 KiB
TypeScript
import { Drafty, type Topic } from 'tinode-sdk';
|
|
|
|
import { uploadFile, upgradeToHttps } from '@/lib/api/upload';
|
|
import { MAX_INBAND_ATTACHMENT_SIZE } from '@/lib/config';
|
|
import { newClientMid, publishWithReattach } from '@/lib/tinode/send';
|
|
|
|
function fileToBase64(file: File): Promise<string> {
|
|
return new Promise((resolve, reject) => {
|
|
const reader = new FileReader();
|
|
reader.onload = () => resolve((reader.result as string).split(',')[1] ?? '');
|
|
reader.onerror = () => reject(reader.error);
|
|
reader.readAsDataURL(file);
|
|
});
|
|
}
|
|
|
|
function imageDimensions(file: File): Promise<{ width: number; height: number }> {
|
|
return new Promise((resolve) => {
|
|
const url = URL.createObjectURL(file);
|
|
const img = new Image();
|
|
img.onload = () => {
|
|
resolve({ width: img.naturalWidth, height: img.naturalHeight });
|
|
URL.revokeObjectURL(url);
|
|
};
|
|
img.onerror = () => {
|
|
resolve({ width: 0, height: 0 });
|
|
URL.revokeObjectURL(url);
|
|
};
|
|
img.src = url;
|
|
});
|
|
}
|
|
|
|
/**
|
|
* Small files go inline as base64 (Drafty.insertImage's `bits` field) -- no upload round trip at
|
|
* all. Larger ones upload first, then reference the returned URL (`refurl`). Simplified from the
|
|
* old app's own urlPromise dance (which inserts an optimistic local preview immediately and lets
|
|
* the upload happen in the background): this awaits the upload before creating the message at all,
|
|
* trading that "shows immediately while uploading" nicety for meaningfully simpler code.
|
|
*/
|
|
export async function sendImage(topic: Topic, file: File): Promise<unknown> {
|
|
const { width, height } = await imageDimensions(file);
|
|
const content =
|
|
file.size <= MAX_INBAND_ATTACHMENT_SIZE
|
|
? Drafty.insertImage(undefined, 0, { mime: file.type, bits: await fileToBase64(file), width, height, filename: file.name, size: file.size })
|
|
: Drafty.insertImage(undefined, 0, {
|
|
mime: file.type,
|
|
refurl: upgradeToHttps((await uploadFile(file, topic.name)).url),
|
|
width,
|
|
height,
|
|
filename: file.name,
|
|
size: file.size,
|
|
});
|
|
const msg = topic.createMessage(content, false);
|
|
msg.head = Object.assign(msg.head || {}, { 'x-im-type': 'image', 'x-im-client-mid': newClientMid() });
|
|
return publishWithReattach(topic, msg);
|
|
}
|
|
|
|
export async function sendFile(topic: Topic, file: File): Promise<unknown> {
|
|
const content =
|
|
file.size <= MAX_INBAND_ATTACHMENT_SIZE
|
|
? Drafty.attachFile(undefined, { mime: file.type, data: await fileToBase64(file), filename: file.name, size: file.size })
|
|
: Drafty.attachFile(undefined, { mime: file.type, refurl: upgradeToHttps((await uploadFile(file, topic.name)).url), filename: file.name, size: file.size });
|
|
const msg = topic.createMessage(content, false);
|
|
msg.head = Object.assign(msg.head || {}, { 'x-im-type': 'file', 'x-im-client-mid': newClientMid() });
|
|
return publishWithReattach(topic, msg);
|
|
}
|
|
|
|
/**
|
|
* `durationMs` is measured by this app's own recording timer, independent of whatever duration
|
|
* metadata (if any) ends up embedded in the audio file itself -- Chrome's MediaRecorder webm output
|
|
* is well known to omit duration metadata entirely (the old app worked around this with the
|
|
* `webm-duration-fix` package; skipped here as a deliberate scope cut since the Drafty `duration`
|
|
* field this app actually displays from doesn't depend on it, only a browser's native <audio>
|
|
* scrubber would).
|
|
*/
|
|
export async function sendVoice(topic: Topic, blob: Blob, durationMs: number): Promise<unknown> {
|
|
const file = new File([blob], `voice.${blob.type.includes('mp4') ? 'm4a' : 'webm'}`, { type: blob.type });
|
|
const content =
|
|
file.size <= MAX_INBAND_ATTACHMENT_SIZE
|
|
? Drafty.insertAudio(undefined, 0, { mime: file.type, bits: await fileToBase64(file), duration: durationMs, size: file.size, filename: file.name })
|
|
: Drafty.insertAudio(undefined, 0, {
|
|
mime: file.type,
|
|
refurl: upgradeToHttps((await uploadFile(file, topic.name)).url),
|
|
duration: durationMs,
|
|
size: file.size,
|
|
filename: file.name,
|
|
});
|
|
const msg = topic.createMessage(content, false);
|
|
msg.head = Object.assign(msg.head || {}, { 'x-im-type': 'voice', 'x-im-client-mid': newClientMid() });
|
|
return publishWithReattach(topic, msg);
|
|
}
|