DEV Community: 박준희

Cloud TTS Chirp3-HD with Caching: Fixing Voice Readout for Accessibility

박준희 — Tue, 23 Jun 2026 10:10:04 +0000

Cloud TTS Chirp3-HD with Caching: Fixing Voice Readout for Accessibility

As a solo developer, keeping the product lean and accessible is paramount. A recent request highlighted a critical need: the ability to have AI chat responses read aloud. This wasn't just about adding a feature; it was about making the platform usable for someone with visual impairments, specifically a user's mother-in-law who struggles with reading text on screen. The initial thought was simple text-to-speech (TTS), but the reality of implementing it well, especially on a single small VM, presented several engineering challenges.

The Genesis: A Need for Voice

The request was clear: "When I ask a question via text, if I don't have time to check it, let me hear the answer via voice." This immediately told me it wasn't about real-time conversational voice, but rather a playback feature for existing text responses. This distinction is crucial for architecture and cost management.

Design Iterations: From Browser to Cloud

The first instinct might be to use the browser's built-in TTS capabilities. However, user feedback quickly shut that down: the native browser voices sounded too robotic and were actively disliked. This pointed towards a cloud-based neural TTS engine. The key requirements that emerged after a couple of back-and-forth discussions were:

Natural Voice: The voice needed to be human-like and pleasant to listen to.
Text Cleaning: Tables, code blocks, and other non-prose elements in the AI's response would create noise if read directly. These needed to be cleaned or handled gracefully.
Efficiency: Repeatedly generating the same audio for the same response was wasteful, both in terms of processing time and cost. A caching mechanism was essential.

Engine Selection: Benchmarking Latency and Quality

I evaluated a couple of cloud TTS options:

Vertex AI Gemini TTS: Offered a natural voice but had a higher latency, taking between 7 to 19 seconds for generation.
Cloud TTS Chirp3-HD: This engine provided a Gemini-level of naturalness and significantly faster generation times, around 2 seconds. It used the ko-KR-Chirp3-HD-Charon/Kore voice, which was consistent with other natural voices used in the product.
Neural2: This was the fastest at around 0.5 seconds but sounded noticeably more like a traditional TTS engine.

Given the balance of speed, naturalness, and voice consistency, Cloud TTS Chirp3-HD was the clear winner. The implementation would involve using its REST API with a service account (SA) that had the cloud-platform scope for authentication, and storing generated audio in Google Cloud Storage (GCS).

Implementation Details: Cleaning, Caching, and Delivery

The implementation involved several components:

Text Cleaning: A new function, clean\_for\_tts, was introduced. This function preprocesses the AI's response to remove or rephrase elements that don't translate well to speech. For instance, code blocks and tables would be replaced with a message like "Please refer to the screen for tables and code." Links, emphasis, and list markers were also stripped to leave only plain text.
Caching Logic: A cache was implemented using GCS. When a request for audio comes in, the cleaned text is hashed. If an MP3 file with that hash exists in the tts-cache/ GCS bucket, it's served immediately. This is a cache HIT, incurs no extra cost, and doesn't deduct from the daily quota. If the file doesn't exist (a cache MISS), the Cloud TTS API is called to generate the audio. The generated audio is then saved to GCS and logged in the usage\_logs table with source='tts'.
Cost Management: To prevent abuse and manage costs on my small VM, a daily cap (TTS\_DAILY\_CAP) was set. This cap applies only to MISSes, not HITs. The cost for TTS generation is approximately $30 per 1 million characters.
API Endpoint: A new API endpoint, POST /chat/tts, was created. This endpoint is publicly accessible (as it's an accessibility feature) and returns the audio data as a base64 encoded string. It handles cache HITs and MISSes.
Nginx Configuration: To ensure the new /api/chat/tts endpoint was correctly routed and not intercepted by other services (like SSE), an exact match configuration was added to Nginx, drawing from lessons learned from previous video upload handling.
Frontend Integration: A "Listen to response" (🔊) button was added to each chat bubble. This button, visible by default for accessibility, triggers the API call. Upon receiving the audio data, it's played back using the browser's new Audio() constructor. The user's selected voice preference is also respected.

A Hidden Bug: Date Encoding Woes

During testing, a critical bug surfaced related to the daily quota tracking. The system was failing to record usage for sessions that timed out or had no speech output, causing a potential leak in the daily cap. This was traced to how dates were handled in the database query for tracking daily generations. Specifically, passing a date as a string $2::date to asyncpg caused a DataError because the string representation wasn't correctly converted. The fix was to perform the date calculation directly within SQL using (now() AT TIME ZONE 'Asia/Seoul')::date instead of relying on string conversion.

Lesson learned: When using asyncpg for date comparisons, it's safer to perform date calculations within SQL or ensure you're passing proper date objects, rather than relying on string casting, especially across different time zones.

Honest Limitations

While this feature significantly enhances accessibility, it's important to be transparent about its limitations:

The voice used is a natural neural voice, not the device's default.
Tables and code blocks are skipped with a "Please refer to the screen" message.
Automatic playback is not enabled to prevent accidental costs and ensure user control.
While cache HITs are free and unlimited, generating new audio deducts from the daily quota.

Furthermore, a note was added that any replies generated by the user's request would require explicit approval before being sent, a standard procedure for user-facing replies.

...building aicoreutility.com in the open...

Documenting the AI Feature Development Journey and Lessons Learned: Sharing Practical Experience

박준희 — Mon, 22 Jun 2026 16:00:00 +0000

Documenting AI Feature Development History and Lessons Learned: Sharing Practical Experience

I felt the need to systematically document the history of AI feature development and the lessons learned during that process. It was particularly important to record the history of various feature additions and insights gained during development for Claude-related documentation.

Attempts and Pitfalls

At first, I just wanted to list the features. But I realized that documenting the problems encountered and the solutions found during the development of each feature would help me avoid getting stuck if I faced similar situations later.

For example, while developing the budget management audit feature, unexpected data consistency issues arose.

# Example code (not actual working code)
def audit_budget(user_id, start_date, end_date):
    transactions = get_transactions(user_id, start_date, end_date)
    total_spent = sum(t['amount'] for t in transactions if t['type'] == 'expense')
    total_income = sum(t['amount'] for t in transactions if t['type'] == 'income')

    if total_spent > total_income * 1.2: # Excessive spending detection logic
        return {"status": "warning", "message": "There's a risk of exceeding the budget."}
    return {"status": "ok", "message": "Budget management is good"}

During this process, there was a bug in the transaction aggregation logic for a specific date range, and it took me over 3 hours to find it.

As I added various features like TTS integration, drawing board functionality, separating the guide hub, improving the settings modal, developing voice tone selection, and showing remaining voice time, I encountered unexpected problems at each stage.

Causes

The problems encountered during development mainly stemmed from the following reasons:

AI-UI-Tutorial Mismatch: It was difficult to properly explain the complexity of AI features through the UI or tutorials.
Gemini Voice Tone Consistency Issues: There were difficulties in consistently managing the various voice tones of the Gemini model.
Native Audio Voice XOR Input Transcription Conflicts: Conflicts occurred between certain audio libraries and the voice input transcription feature.

Solutions

Ultimately, the solution was to systematically document the history of major feature development and the lessons learned during development in the Claude-related documentation. For each feature, I included the following:

Feature Name: Clearly stated which feature was developed.
Development Background: Explained why this feature was necessary.
Development Process: Outlined the main problems encountered and the solutions attempted.
Final Solution: Provided the actual working code and the reasoning behind it.
Lessons Learned: Detailed what was learned while developing this feature.

As an example, the conflict issues encountered while developing the voice tone selection feature were resolved as follows:

# Example code (not actual working code)
from some_audio_library import AudioSynthesizer
from speech_recognition_library import SpeechRecognizer

class VoiceManager:
    def __init__(self):
        self.synthesizer = AudioSynthesizer()
        self.recognizer = SpeechRecognizer()
        self.available_voices = self.synthesizer.get_available_voices()

    def set_voice(self, voice_id):
        if voice_id in self.available_voices:
            self.synthesizer.set_voice(voice_id)
            print(f"Voice tone set to {voice_id}.")
        else:
            print(f"Error: Voice tone {voice_id} not found.")

    def speak(self, text):
        self.synthesizer.speak(text)

    def recognize_speech(self):
        return self.recognizer.recognize()

# Separating voice tone settings and voice output to prevent conflicts
voice_manager = VoiceManager()
voice_manager.set_voice("gemini-standard") # Set Gemini voice tone
voice_manager.speak("Hello.") # Voice output
recognized_text = voice_manager.recognize_speech() # Voice input transcription

This code clearly separated AudioSynthesizer and SpeechRecognizer so they wouldn't interfere with each other's operations, and prevented conflicts by managing voice tone settings and voice output in separate methods.

Results

The history of AI feature development and the lessons learned during the development process have been systematically documented in the Claude-related documentation.
The problems encountered and solutions found during the development of each feature are now clear, allowing for quicker responses to similar issues in the future.
Insights gained during development (AI-UI-Tutorial mismatch, Gemini voice tone consistency, native-audio voice XOR input transcription conflicts, etc.) have been documented, contributing to knowledge sharing within the team.

Summary — How to Avoid Falling into the Same Traps

[ ] When developing new AI features, review their suitability with UI/UX and tutorials from the initial stages.
[ ] When using multiple AI models (especially for voice), establish a strategy beforehand to maintain consistency in voice tones and output.
[ ] When integrating external libraries or SDKs, test with the possibility of conflicts with existing features in mind.
[ ] Make it a habit to document problems, "sprints" (wasted efforts), and solutions encountered during development in detail.
[ ] When documenting, strive to present generalized causes and solutions rather than relying on specific infrastructure or app names.

Reducing Unnecessary Costs by Automatically Ending Voice Call Sessions

박준희 — Sat, 20 Jun 2026 16:00:00 +0000

Ever faced the issue of voice call sessions staying active unnecessarily, leading to unexpected costs? This often happens, especially in Live session environments. In this post, I'll share my experience implementing automatic session termination for silence or explicit end-of-call signals to reduce costs.

Attempts and Pitfalls

Initially, I thought of a simple logic: if there's no speech for a certain period, just terminate the session. But it turned out to be trickier than I expected. It was hard to distinguish between a user briefly pausing their speech and them actually wanting to end the call.

# Initial attempt: Simple silence timeout
def check_silence_and_terminate(session_id, last_activity_time, timeout_duration):
    current_time = datetime.now()
    if (current_time - last_activity_time).total_seconds() > timeout_duration:
        print(f"Session {session_id} terminated due to silence.")
        # Session termination logic...

With this code, there was a risk of the session being terminated even when the user was just catching their breath or taking a moment to think. Ultimately, I spent about 3 hours fiddling with this approach without achieving satisfactory results.

The Root Cause

The core of the problem was understanding 'user intent.' Relying solely on the absence of speech led to false positives. We needed to differentiate between cases where the user clearly expressed their intention to end the call (e.g., "I'll hang up," "End") and cases where they simply remained silent.

The Solution

So, in the end, I implemented the session termination logic by combining two conditions:

Silence Detection: When there's no voice input for a specific duration.
Explicit End-of-Call Intent Detection: Detecting speech containing specific keywords (e.g., "종료" (end), "끊어" (hang up), "안녕" (bye)).

I modified the logic to terminate the session only when both these conditions are met.

# Improved session termination logic
def should_terminate_session(session_data):
    current_time = datetime.now()
    last_activity_time = session_data['last_activity_time']
    silence_timeout = 60  # 60 seconds of silence
    last_utterance = session_data.get('last_utterance', '')
    keywords_to_terminate = ['종료', '끊어', '안녕', '마칠게']

    # 1. After a certain period of silence
    if (current_time - last_activity_time).total_seconds() > silence_timeout:
        print(f"Session {session_data['id']} is a candidate for termination due to silence.")
        return True

    # 2. When the user explicitly expresses intent to end
    for keyword in keywords_to_terminate:
        if keyword in last_utterance.lower():
            print(f"Session {session_data['id']} detected explicit intent to terminate: '{last_utterance}'")
            return True

    return False

# Example data
session_info = {
    'id': 'session_abc',
    'last_activity_time': datetime.now() - timedelta(seconds=70),
    'last_utterance': 'Yes, I understand. See you next time.'
}

if should_terminate_session(session_info):
    print("Proceeding with session termination...")
else:
    print("Session ongoing...")

session_info_2 = {
    'id': 'session_xyz',
    'last_activity_time': datetime.now() - timedelta(seconds=10),
    'last_utterance': 'Yes, I'll hang up now.'
}

if should_terminate_session(session_info_2):
    print("Proceeding with session termination...")
else:
    print("Session ongoing...")

Thanks to this logic, sessions are no longer unnecessarily terminated when the user pauses briefly, while still accurately detecting when the user intends to end the call. This has allowed for smoother, more cost-effective operation.

Results

Reduced unnecessary extension of Live session durations.
Confirmed cost savings for voice call-related services.
Increased cost-efficiency without compromising user experience.

Summary — To Avoid the Same Pitfalls

[ ] When implementing voice session termination logic, do not rely solely on silence duration.
[ ] Consider explicit end-of-call intent signals from the user (e.g., keyword detection) as well.
[ ] During testing, thoroughly validate with various speech patterns (brief pauses, intentional closing remarks, etc.).

Node.js Speech Transcription Bug: Unsaved Content Due to Missing `conversation_id`, Resolved by Bridge Forwarding

박준희 — Fri, 19 Jun 2026 16:00:00 +0000

Did you run into an issue where transcribed speech content wasn't being saved? I had a similar experience, and it turned out to be caused by not properly passing the conversation_id. I'd like to share how I solved it in this post.

Attempts and Pitfalls

At first, I suspected a problem with the speech transcription API response itself. I hypothesized that if the conversation_id wasn't passed correctly during the API call, the server wouldn't be able to properly match the transcription results. So, I tried explicitly passing the conversation_id through a bridge when making the API call.

// Previous code (assumed)
async function transcribeAudio(audioBlob) {
  const response = await fetch('/api/transcribe', {
    method: 'POST',
    body: audioBlob,
    headers: {
      'Content-Type': 'audio/wav',
      // conversation_id missing or incorrectly passed
    },
  });
  const data = await response.json();
  return data;
}

However, as expected, passing the conversation_id via a bridge didn't resolve the issue. There were no specific error messages in the server logs, and the transcription results were just empty. After about 3 hours of struggling, I realized that the conversation_id needed to be passed in a different way, not in the API request body or headers.

Cause

The root cause of the problem was that the conversation_id was not being transmitted correctly as part of the API request. The speech transcription service uses the conversation_id to uniquely identify each speech session. If this value was missing or passed through the wrong channel, the server wouldn't know which conversation the transcription results belonged to, and thus couldn't save the data.

Solution

The solution was to clearly specify and pass the conversation_id as a dedicated field within the API request. Additionally, I added WARNING logging as a safeguard and modified the code to store a fallback response text if the text field was missing in the response.

// Modified code
async function transcribeAudio(audioBlob, conversationId) {
  const formData = new FormData();
  formData.append('audio', audioBlob);
  formData.append('conversation_id', conversationId); // Explicitly passed as a field

  try {
    const response = await fetch('/api/transcribe', {
      method: 'POST',
      body: formData,
    });

    const data = await response.json();

    if (!data.text) {
      console.warn(`[Transcribe] No text found for conversation_id: ${conversationId}. Response:`, data);
      // Add logic to temporarily store response.text if the text field is missing in the response (example)
      // Actual implementation may vary depending on the situation
      if (data.raw_response) { // Arbitrary field name, depends on actual API response
         // Save logic...
      }
    }
    return data;
  } catch (error) {
    console.error(`[Transcribe] Error transcribing audio for conversation_id: ${conversationId}`, error);
    throw error;
  }
}

By explicitly adding the conversation_id to FormData and modifying the server to parse that field, the transcription content started being saved correctly.

Results

The bug where transcribed speech content wasn't being saved has been completely resolved.
Adding WARNING logging and fallback save logic has made it much easier to identify the cause and debug when issues arise.
Clarifying the API request structure has improved code readability and maintainability.

Summary — How to Avoid the Same Pitfall

[ ] When using speech transcription APIs, double-check the API documentation to confirm how the conversation_id should be passed.
[ ] The conversation_id typically needs to be explicitly sent as a specific field in the request body or as a header.
[ ] When problems occur, don't just rely on server logs; enhance client-side logging to thoroughly inspect request and response data.
[ ] Consider implementing fallback logic to handle unexpected values in API responses.

Next.js 14: 'Could not find the module in the React Client Manifest' — the real cause nobody tells you

박준희 — Fri, 19 Jun 2026 05:42:33 +0000

Next.js 14: 'Could not find the module in the React Client Manifest' — the real cause nobody tells you

As a solo developer running a full AI product on a single, modest VM, every deployment is a high-stakes operation. When things go wrong, there's no team to swarm the problem; it's just me, the logs, and a rapidly ticking clock. Recently, a routine Next.js 14 deployment failed spectacularly with an error message that, at first glance, offered little help: 'Could not find the module in the React Client Manifest'.

This error typically surfaces during the build process of a Next.js application, especially when using React Server Components (RSC). The React Client Manifest is a crucial artifact that Next.js uses to map client-side components and their dependencies. When it can't find a module it expects, it means something has gone awry in how the build is being generated or where it's being executed.

The Symptom: A Cryptic Build Failure

The build pipeline, which relies on GitHub Actions to deploy changes to my single VM, ground to a halt. The logs were filled with this specific error, pointing to an issue with the client manifest generation. My initial thoughts went to the usual suspects:

Corrupted cache?
Dependency mismatch?
A bug in a recent Next.js update?

I meticulously checked my package.json, ran npm ci to ensure clean dependencies, and even tried reverting to a previous, known-good commit. Nothing. The error persisted, mocking me with its vagueness. The application itself was running fine in development, so the issue was clearly environment or build-specific.

The Wrong Turns: Chasing Ghosts

My first instinct was to dive deep into the Next.js documentation and community forums. I found similar errors, often attributed to:

Incorrectly configured next.config.js.
Issues with the app directory structure.
Problems with serverless function configurations.

I spent hours scrutinizing my configuration files, ensuring the app directory was correctly set up, and verifying that my serverless function settings (though not strictly applicable to my single VM setup, I checked for any residual configuration) were sound. Still, no luck. The error message was a red herring, leading me down paths that were irrelevant to the actual problem.

The Real Root Cause: The Build's Working Directory

The breakthrough came when I started thinking about the execution context of the build command itself. My GitHub Actions workflow was designed to check out the code, install dependencies, and then run the Next.js build command. The error message mentioned the client manifest, which is generated during the build. What if the build command wasn't running in the expected directory?

The key insight came from a subtle detail in the GitHub Actions logs. The build command was being executed, but it seemed to be operating from a different working directory than anticipated. Specifically, the build was likely running from the root of the repository *after* a checkout operation, but perhaps some cached or intermediate build artifacts were expected to be in a specific sub-directory, or the build process itself was sensitive to the current working directory.

The MATERIAL mentions nextjs-package-json-deleted-build-failure-recovery-2026 and related entries like nextjs-rsc-client-manifest-build-cwd. This suggests that the build process, particularly with RSCs, can be sensitive to the current working directory (cwd) during execution. If the build script isn't explicitly run from the project root where package.json and next.config.js reside, or if it's executed in a way that the build tools don't correctly infer the project root, it can lead to manifest generation errors.

In my case, the GitHub Actions workflow had recently been updated, and a subtle change in how the code was checked out or how subsequent commands were executed likely shifted the default working directory for the build step. The Next.js build process, when invoked without explicitly setting the correct working directory, might not correctly locate necessary files or generate artifacts in the expected locations, leading to the manifest error.

The Reproducible Fix: Explicitly Setting the Working Directory

The fix was surprisingly simple, yet elusive because it wasn't directly indicated by the error message itself. I needed to ensure that the Next.js build command was executed from the correct directory within the GitHub Actions runner. This is often done by changing the directory before running the command.

My updated GitHub Actions workflow step now looks something like this (simplified):

- name: Build Next.js App
  run: |
    cd my-app-directory # Explicitly change to the app's root directory
    npm run build

By adding the cd my-app-directory command before npm run build, I explicitly told the runner where to find the project's root, including package.json and other configuration files. This ensured that the Next.js build process could correctly locate all its dependencies and generate the client manifest without errors.

The Lesson: Beware of Implicit Working Directories

This incident was a stark reminder that even with modern tooling, the fundamentals of execution context matter. When running builds, especially in CI/CD environments, always be mindful of the current working directory. Implicit assumptions about where commands are run can lead to obscure errors that are difficult to debug.

For anyone else encountering the 'Could not find the module in the React Client Manifest' error in Next.js 14, especially within a CI environment:

Verify your build command's working directory. Ensure it's run from the root of your Next.js project.
Check your CI/CD configuration for any recent changes that might affect the execution context of your build steps.
Clean builds are good, but context is king. Sometimes, the issue isn't what's in your code, but where your code is being built.

It's the unglamorous reality of solo development: a single line change in a CI script can bring the whole operation down, and the debugging process is a lonely journey through cryptic error messages.

...building aicoreutility.com in the open...

Chatbot Zero-Downtime Deployment Failure? Solved with Backend Rolling Restart (2026)

박준희 — Thu, 18 Jun 2026 16:00:01 +0000

Ever been frustrated by service downtime when deploying your chatbot? If you've aimed for zero-downtime deployments but ended up inconveniencing users repeatedly, this post might help. I want to share my experience implementing stable deployments using a backend rolling restart strategy.

Attempts and Pitfalls

Initially, I naturally tried to stick with the existing deployment method. However, since chatbot services need to process user requests in real-time, even a brief pause was critical. So, I decided to adopt a rolling restart approach, gradually replacing backend servers.

Similar to Blue-Green deployments, this involves preparing a new version (Green) and gradually shifting traffic from the old version (Blue). I also included health checks to ensure the new version was healthy before taking over.

# Example: Start deploying the new version
kubectl apply -f new-backend-deployment.yaml

# Example: Wait until new version Pods are ready
kubectl rollout status deployment/backend-deployment -n chatbot --timeout=5m

# Example: Gradually terminate old Pods and switch traffic
# (This is where an unexpected issue occurred)

However, an unforeseen problem arose during this process. Even though all the new version Pods were ready, traffic wasn't being switched correctly when the old Pods were terminated, causing some requests to be dropped. It seemed like the rolling restart wasn't functioning as intended. After three hours of struggling, I discovered the cause...

The Cause

The issue wasn't with the rolling restart logic itself, but with the service's state management approach. The chatbot service maintained specific session information in memory. When the old Pods were terminated, this information disappeared abruptly. When requests then went to the new Pods, sessions were broken. In essence, the Pods themselves were terminating correctly, but the service's state led to a poor user experience.

The Solution

To fix this, I implemented a strategy to move session information to an external storage (like Redis). This way, even when old Pods are terminated, the session data remains intact. New Pods can then retrieve this data and seamlessly resume existing sessions.

# Example: Kubernetes Deployment configuration (partial)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-chatbot
spec:
  replicas: 3 # Example: running with 3 Pods
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Set to ensure only one Pod is unavailable at a time
      maxSurge: 1       # Allow up to one new Pod to be created above desired replicas
  # ... (other configurations)

# Example: Python code to load session data from Redis (based on Flask)
from flask import Flask, session
import redis

app = Flask(__name__)
app.config['SECRET_KEY'] = 'your_secret_key' # Use a secure key in production
redis_client = redis.StrictRedis(host='your-redis-host', port=6379, db=0)

@app.before_request
def load_session_from_redis():
    session_id = request.cookies.get('session_id') # Or other session identifier
    if session_id:
        session_data = redis_client.get(f'session:{session_id}')
        if session_data:
            # Logic to decode and restore session data
            pass

@app.route('/')
def index():
    # ...
    pass

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

By externalizing session information like this, I ensured that user sessions are not interrupted and seamlessly continue even as Pods are terminated and new ones start. The health checks remain valid, and traffic is only switched when all Pods are in a healthy state.

Results

Downtime during deployment has been reduced to zero.
User experience has significantly improved, with no more session 끊김 (session interruptions).
The rolling restart strategy has been successfully applied, enhancing deployment stability.

Summary — How to Avoid the Same Pitfall

If you're attempting rolling restarts for zero-downtime deployments, make sure to check the following:

[ ] Verify that your service's state (like session information) is managed independently of the Pod's lifecycle (e.g., using external storage).
[ ] Ensure your Deployment strategy is configured with maxUnavailable and maxSurge to allow for gradual traffic shifting.
[ ] Validate that your readinessProbe and livenessProbe accurately reflect the actual health of your service.
[ ] After deployment, continuously monitor actual user traffic to detect any unexpected errors.

Measuring Backend Power Levels: Securing Objectivity by Reflecting Real-time Congestion

박준희 — Wed, 17 Jun 2026 16:00:00 +0000

Want to reflect real-time congestion when measuring power scale? Or have you questioned the objectivity of existing measurement methods? This post covers how to enhance the objectivity of power scale measurement and reflect real-time congestion using Seoul's urban data.

Attempts and Pitfalls

Initially, I changed the power scale measurement method to simply record the daily maximum value for each date. The goal was to ensure objectivity by using Seoul's urban data as the primary indicator.

However, I realized that it lacked the ability to reflect real-time congestion. For instance, if there was an event on a specific day causing congestion to surge, recording only the daily maximum might make it appear not much different from the usual congestion levels.

So, I considered adding real-time congestion data for Olympic Park as a secondary indicator. I attempted to retrieve real-time congestion information through the Seoul Urban Data API.

# Example: Calling Seoul Urban Data API (Actual API endpoint may vary)
import requests

api_key = "YOUR_API_KEY"
olympic_park_data_url = f"https://api.seoul.go.kr/v1/citydata/olympic_park_congestion?apiKey={api_key}"

try:
    response = requests.get(olympic_park_data_url)
    response.raise_for_status() # Raise an exception for HTTP errors
    congestion_data = response.json()
    print(congestion_data)
except requests.exceptions.RequestException as e:
    print(f"API call error: {e}")

During this process, unexpected issues arose with the API response format and data parsing. Sometimes the data was empty, or it came in a format different from what was expected. After about 3 hours of struggling, I figured out a way to reliably handle the API responses.

The Cause

To improve the objectivity of the power scale measurement method and reflect real-time congestion, both aspects needed to be considered.

Ensuring Objectivity of the Primary Indicator: Recording the daily maximum value for each date could enhance objectivity by showing the peak at a specific point in time.
Reflecting Real-time Changes: It was necessary to detect and incorporate unexpected congestion situations into the measurement by utilizing real-time congestion data from highly populated areas like Olympic Park as a secondary indicator.

The Solution

Ultimately, I changed the power scale measurement method as follows and updated the related documentation.

Primary Indicator: Maintain the recording of the daily maximum value for each date.
Secondary Indicator: Add real-time congestion data for Olympic Park. This data is periodically collected through the Seoul Urban Data API.

# Example: Data collection and storage logic (simplified)
import datetime

def get_olympic_park_congestion():
    # ... (API call and data parsing similar to previous code)
    # Return actual congestion value (e.g., 0.8 - very congested)
    return 0.8

def update_power_scale_measurement():
    today = datetime.date.today()
    current_max_scale = get_daily_max_power_scale(today) # Existing function to get daily max
    current_congestion = get_olympic_park_congestion()

    # Logic to update daily maximum
    if current_congestion > current_max_scale:
        update_daily_max_power_scale(today, current_congestion)

    # Store secondary indicator data (e.g., in a separate table or log)
    log_congestion_data(today, current_congestion)

    print("Power scale measurement data update complete.")

# Call periodically during actual execution
# update_power_scale_measurement()

This approach allows us to understand the usual power scale through the daily maximum while also detecting sudden congestion changes with the secondary indicator, thus increasing the realism of the measurement.

Results

The objectivity of the power scale measurement method has been improved.
The realism of the measurement has increased with the incorporation of real-time congestion data.
The related documentation has been updated to include the latest data reflections and changes in the measurement method.

Summary — To Avoid the Same Pitfalls

[ ] When measuring power scale, consider real-time congestion data as a secondary indicator in addition to the daily maximum.
[ ] When integrating external APIs, implement robust exception handling for potential response format issues or data omissions.
[ ] When restarting WAS (e.g., gunicorn), verify that data collection and measurement logic resume normally. (Previously, there was an issue where data was lost after restarts.)

How to Fix Search Engine Indexing Issues Caused by robots.txt Block Errors

박준희 — Tue, 16 Jun 2026 16:00:00 +0000

Is your search engine not indexing important pages on your site properly? You might be experiencing issues with certain paths being blocked by robots.txt settings, causing them to be omitted from search results. In this post, I'll share a similar situation I encountered and how I resolved it.

Attempts and Pitfalls

At first, I naturally assumed there was a syntax error in the robots.txt file itself, or that it contained incorrect directives. So, I meticulously reviewed the file's contents again.

User-agent: *
Disallow: /chat

I suspected that a setting like this, blocking the /chat path, was the culprit. This path indeed contained a lot of content related to the user interface.

However, the robots.txt syntax was perfect, and there seemed to be no issues with other search engine-related settings. I spent hours poring over documentation related to robots.txt, but struggled to find a clear solution. The "Indexed, though blocked by robots.txt" warning kept appearing in the search engine's developer tools.

The Cause

In the end, the problem wasn't an error in the robots.txt file itself, but rather that the blocking setting was unintentionally preventing important pages from being indexed. Specifically, some pages within the /chat path contained crucial content that the search engine needed to index, and blocking the entire path with Disallow was the mistake.

The Solution

The solution was surprisingly simple. Instead of blocking the entire /chat path, I modified the settings to explicitly block only the specific sub-paths that I genuinely wanted search engines to avoid.

User-agent: *
Disallow: /chat/private-conversations/

With this change, other pages under /chat can still be indexed, while only the sensitive content located in the /chat/private-conversations/ path is blocked.

The Result

Search engines began indexing the relevant pages of my site correctly.
The "Indexed, though blocked by robots.txt" warning in the developer tools disappeared.
I observed an overall improvement in my site's search visibility.

In Summary — To Avoid the Same Pitfall

[ ] When configuring robots.txt, double-check if the paths specified in Disallow are unintentionally blocking access to important pages.
[ ] Consider explicitly specifying only the sub-paths that absolutely need to be blocked, rather than blocking an entire path.
[ ] After making changes to robots.txt, always verify the changes using search engine developer tools, including the indexing status and the robots.txt tester.
[ ] Remember that robots.txt is a 'request' to search engines not to crawl, not a 'command' that forces them.

Resolving CP949 Errors in Local LLM Benchmarking and Building an Automatic Model Recommendation System

박준희 — Mon, 15 Jun 2026 16:00:00 +0000

Ever run into CP949 encoding errors when benchmarking local LLMs, or felt frustrated by the lack of model management features? In this post, I'll share my experience overcoming CP949 encoding issues and building an automatic model recommendation system to enhance local model research and management capabilities.

Attempts and Pitfalls

Initially, I wanted to build a simple feature in the admin page to switch and benchmark local models. I also prepared a more diverse set of benchmark questions in Korean.

// riel_agent/src/app/admin/tabs/LocalModelLabTab.tsx (excerpt)

import { Button, Select, Input } from '@mantine/core';
import { useState, useEffect } from 'react';
import {
  getLocalModels,
  switchLocalModel,
  runBenchmark,
  getBenchmarkResults,
} from '../../api/admin'; // Actual API call functions

function LocalModelLabTab() {
  const [models, setModels] = useState<string[]>([]);
  const [selectedModel, setSelectedModel] = useState<string>('');
  const [benchmarkQuestions, setBenchmarkQuestions] = useState<string[]>([]);
  const [benchmarkResults, setBenchmarkResults] = useState<any>(null);

  useEffect(() => {
    // Load local model list
    getLocalModels().then(setModels);
    // Load Korean benchmark questions (expanded to 25)
    // ...
  }, []);

  const handleModelChange = async (modelName: string) => {
    await switchLocalModel(modelName); // Actual model switching API
    setSelectedModel(modelName);
  };

  const handleRunBenchmark = async () => {
    const results = await runBenchmark(selectedModel, benchmarkQuestions); // Actual benchmark execution API
    setBenchmarkResults(results);
  };

  // ... UI rendering ...

  return (
    <div>
      <Select
        label="Select Local Model"
        data={models}
        value={selectedModel}
        onChange={handleModelChange}
      />
      <Button onClick={handleRunBenchmark}>Run Benchmark</Button>
      {/* Results display section */}
    </div>
  );
}

export default LocalModelLabTab;

Switching models and expanding questions were relatively straightforward. The problem arose when running benchmarks, especially with Korean data, where I frequently encountered CP949 encoding errors.

UnicodeEncodeError: 'cp949' codec can't encode characters in position 1-3: illegal multibyte sequence

Seeing this error message, I initially thought it was just a Korean string processing issue. So, I tried changing the encoding settings in Python files or explicitly encoding/decoding strings to utf-8. However, after hours of struggling, the problem persisted.

# riel_backend/api/local_llm.py (part of initial attempts)

import json

def process_text_with_model(text: str, model_name: str) -> str:
    # ... Model call logic ...
    # CP949 error occurred here
    # text = text.encode('utf-8').decode('cp949', errors='ignore') # Attempts like this
    # ...
    pass

The Cause

After hours of debugging, I finally pinpointed the root cause. It wasn't just an encoding issue with the Python script itself. The local LLM worker was attempting to forcibly convert data to CP949, the default encoding on certain environments (especially Windows), during the process of handling and saving model responses.

# tools/local_llm_worker/worker.py (suspected point of failure)

def save_output(output_data: dict):
    # ...
    with open(output_file_path, 'w', encoding='cp949') as f: # <-- Problem occurred here
        json.dump(output_data, f, ensure_ascii=False)
    # ...

The json.dump function, when used with ensure_ascii=False, outputs Unicode characters as they are. However, specifying encoding='cp949' during file writing caused an error because it tried to convert them to that encoding.

The Solution

The fix was simple: modify the local LLM worker to explicitly use utf-8 encoding when saving files.

# tools/local_llm_worker/worker.py (after modification)

import json

def save_output(output_data: dict):
    # ...
    with open(output_file_path, 'w', encoding='utf-8') as f: # <-- Changed to utf-8
        json.dump(output_data, f, ensure_ascii=False, indent=4) # Added indent for better readability
    # ...

Along with this, I built a system to automatically download models, benchmark them, and recommend better ones.

# tools/local_llm_bench/auto_bench.py (automatic benchmark loop)

import os
import json
import time
from typing import List, Dict

# Import necessary functions (e.g., download_model, run_single_benchmark, get_best_model)
from .utils import download_model, run_single_benchmark, get_best_model
from ..local_llm_worker.worker import process_prompt # Import prompt processing function from worker module

def auto_benchmark_loop(model_dir: str, benchmark_prompts_path: str, num_iterations: int = 5):
    current_best_model = None
    candidate_models = ["model_a", "model_b", "model_c"] # Actual model list would be fetched dynamically

    for i in range(num_iterations):
        print(f"Iteration {i+1}/{num_iterations}")

        # 1. Download candidate models (if they don't exist yet)
        for model_name in candidate_models:
            if not os.path.exists(os.path.join(model_dir, model_name)):
                print(f"Downloading {model_name}...")
                download_model(model_name, model_dir) # Actual download function

        # 2. Benchmark current best model
        if current_best_model:
            print(f"Benchmarking current best model: {current_best_model}")
            results = run_single_benchmark(current_best_model, benchmark_prompts_path)
            # Analyze and save results
            # ...

        # 3. Benchmark all candidate models
        all_results: Dict[str, List[float]] = {}
        for model_name in candidate_models:
            print(f"Benchmarking candidate model: {model_name}")
            results = run_single_benchmark(model_name, benchmark_prompts_path)
            all_results[model_name] = results['scores'] # Example: list of scores

        # 4. Select best model based on latest results
        new_best_model = get_best_model(all_results) # Actual best model selection logic

        if new_best_model != current_best_model:
            print(f"New best model found: {new_best_model}. Updating...")
            current_best_model = new_best_model
            # Notify the system about the best model via admin API, etc.
            # switchLocalModel(current_best_model) # Example
        else:
            print("Current best model remains the best.")

        time.sleep(60 * 5) # Wait before the next iteration

if __name__ == "__main__":
    MODEL_DIRECTORY = "/path/to/local/models" # Actual path
    PROMPTS_FILE = "tools/local_llm_bench/prompts.json"
    auto_benchmark_loop(MODEL_DIRECTORY, PROMPTS_FILE, num_iterations=10)

During this process, I discovered that the Gemma2:2b model performed significantly better than the EXAONE model I was using previously. I documented and shared this finding.

## Gemma2:2b Model Performance Analysis (As of June 15, 2026)

Recently, I've been analyzing the performance of various models using my automated local model benchmarking system. In particular, I've confirmed that the **Gemma2:2b** model shows a significant advantage over the **EXAONE** model, which I was using previously, in terms of Korean language processing and overall response quality.

**Key Observations:**

*   **Response Speed:** Gemma2:2b maintained a similar response speed to EXAONE while generating higher quality results.
*   **Korean Comprehension:** Gemma2:2b provided much more accurate and natural answers to complex and nuanced Korean questions.
*   **Creative Generation:** Gemma2:2b also scored higher in its ability to generate creative responses to given prompts.

These findings suggest that Gemma2:2b should be prioritized when building local LLM systems in the future.

Results

Research, management, and benchmarking capabilities for local models have been significantly enhanced.
The CP949 encoding errors encountered during benchmark execution have been completely resolved, improving system stability.
It was objectively confirmed and documented that the Gemma2:2b model outperforms EXAONE.

Summary — To Avoid the Same Pitfalls

[ ] When performing file I/O in a local environment, do not rely on the operating system's default encoding (CP949 on Windows); always explicitly use utf-8.
[ ] When using Python's json.dump, prevent Korean garbling and encoding errors by specifying encoding='utf-8' during file writing, along with the ensure_ascii=False option.
[ ] Build automated scripts for local LLM model management and benchmarking to improve model performance and ensure efficient operation.
[ ] Regularly benchmark various models, and when you discover a high-performing model, immediately document it and incorporate it into your system.
[ ] When encountering errors like UnicodeEncodeError: 'cp949' codec can't encode characters..., investigate not only the encoding issues of the code itself but also the entire system environment and file I/O logic.

Node.js Backend: Visualizing the Observer Pattern and Improving Data Processing Performance

박준희 — Sun, 14 Jun 2026 16:00:00 +0000

Improving Node.js Backend: Visualizing Observer Pattern and Enhancing Data Processing Performance

I noticed a deficiency in visualizing observer functionality and handling data within the user interface and backend logic. I tried a few things to fix this, and I'd like to share the process.

Attempts and Pitfalls

Initially, I focused on visualizing nationwide spread phenomena. The idea was to show the spread process by adjusting the activity time for each province using a slider. However, I realized this approach made it difficult to properly represent complex interactions.

// Attempt 1: Visualizing Spread (Conceptual Code)
function visualizeSpread(simulationData, timeSliderValue) {
  const currentTimeData = simulationData.filter(d => d.time <= timeSliderValue);
  // Logic to visualize spread on the map based on currentTimeData
  console.log(`Visualizing spread at time: ${timeSliderValue}`);
  // ... actual visualization code ...
}

Next, I tried to implement a "conflicting intertwined chains" feature to visualize the self-reinforcing loops between the government and citizens on the ground. The idea was interesting, but I was stumped on how to structure and process the data.

// Attempt 2: Conflicting Intertwined Chains (Conceptual Code)
function createConflictingChains(governmentActions, citizenReactions) {
  const chains = [];
  // Analyze interactions between governmentActions and citizenReactions to create chains
  // Example: Government Policy A -> Citizen Reaction B -> Government Policy C (amplified by Reaction B)
  console.log("Attempting to create conflicting chains...");
  // ... actual logic ...
  return chains;
}

Critically, when I tried to add functionality to retroactively extract these conflicting chains and separate mega-calls, the data processing volume became unmanageable. I wasted a significant amount of time dealing with unexpected performance degradation and increased complexity. After 3 hours of struggling, I realized that simple visualization couldn't adequately capture a complex system.

The Cause

Ultimately, the problem lay in the data processing and visualization methods between the user interface and the backend logic. The existing approach didn't sufficiently reflect the complexity of spread phenomena or interactions, and data processing efficiency was low. In particular, there was a lack of mechanisms needed to effectively model and visualize dynamic interactions like self-reinforcing loops.

The Solution

I improved the user interface and backend logic to enhance the visualization and data processing capabilities of the 'observer' feature. While keeping the visualization of nationwide spread phenomena with a provincial activity time slider, I newly implemented the 'conflicting intertwined chains' feature to represent the self-reinforcing loops between the government and citizens.

// Solution: Improved Data Processing and Visualization Logic (Conceptual Code)
class ObserverVisualizer {
  constructor(backendService) {
    this.backendService = backendService;
  }

  async visualizeSpreadOverTime(simulationId) {
    const spreadData = await this.backendService.getSpreadData(simulationId);
    // Visualize with the provincial activity time slider using spreadData
    console.log("Visualizing spread with improved logic.");
    // ... actual visualization implementation ...
  }

  async visualizeConflictingChains(interactionData) {
    const processedChains = await this.backendService.processAndExtractChains(interactionData);
    // Visualize processedChains as 'conflicting intertwined chains'
    console.log("Visualizing conflicting chains and mega calls.");
    // ... actual visualization implementation ...
  }
}

// Example of calling the actual backend service
const backend = new BackendService(); // Actual backend service instance
const visualizer = new ObserverVisualizer(backend);

// Visualize nationwide spread phenomena
visualizer.visualizeSpreadOverTime('some-simulation-id');

// Visualize government-citizen interactions
visualizer.visualizeConflictingChains(collectedInteractionData);

Furthermore, I enhanced data processing efficiency by adding functionality to retroactively extract these conflicting chains and separate mega-calls. This allowed for a clearer understanding of the dynamic interactions within complex systems.

Results

Effectively visualized nationwide spread phenomena through a provincial activity time slider.
Successfully implemented a visualization feature for 'conflicting intertwined chains' representing self-reinforcing loops between the government and citizens.
Increased data processing efficiency by adding retroactive extraction of conflicting chains and mega-call separation.

Takeaways — To Avoid the Same Pitfalls

[ ] When visualizing complex interactions, go beyond simple data representation and adopt modeling that can reflect the dynamic characteristics of the system.
[ ] When implementing feedback mechanisms like self-reinforcing loops, thorough consideration of data structure design and processing logic must come first.
[ ] For large-scale data processing, it's crucial to identify potential performance bottlenecks in advance and apply efficient algorithms and data structures.
[ ] The integration between the user interface and backend logic should be achieved through clear API design and consistent data flow.

Vertex AI 'Resource exhausted' (429) API Rate Limit on a Single VM

박준희 — Sat, 13 Jun 2026 09:30:00 +0000

Vertex AI 'Resource exhausted' (429) API Rate Limit on a Single VM

Building and running a full-fledged AI product, aicoreutility.com, as a solo developer on a single, modest virtual machine presents a unique set of challenges. It's a constant dance between functionality, cost, and the sheer limitations of the infrastructure. Today, I want to share a scar from this journey: a persistent 429 'Resource exhausted' error from Google Cloud's Vertex AI API that brought a critical part of my service to a halt.

The symptom was simple, yet infuriating: API calls to Vertex AI were intermittently failing, returning a 429 RESOURCE_EXHAUSTED error. The accompanying message was equally unhelpful for a solo dev on a budget: 'Resource exhausted. Please try again later. Please refer to https://cloud.google.com/vertex-ai/docs for more information.'. This wasn't a constant failure, which made it even harder to pin down. It would work for a while, then suddenly start failing, only to recover later. This erratic behavior suggested a rate-limiting issue, but the context of my setup made it perplexing.

My initial thought process was a bit scattered. Was it a bug in my application code? Was I making too many requests in a short period? Was there a sudden surge in global traffic to Vertex AI that was impacting shared resources? Given I'm running on a single small VM, I don't have the luxury of massive parallel processing or distributed systems that might inadvertently hammer an API. My request volume, while growing, felt modest.

I started by scrutinizing my own code. I checked the API client implementation, ensuring I wasn't inadvertently creating infinite loops or making redundant calls. I reviewed the logic for how I was interacting with the Vertex AI models. I added more detailed logging around every API call, capturing request payloads, response status codes, and timings. This helped confirm that the errors were indeed originating from Vertex AI itself, and the 429 status code was consistent.

The next step was to investigate the rate limits. Google Cloud documentation is extensive, but pinpointing the exact limit for my specific use case on Vertex AI, especially when running from a single VM without a dedicated, high-volume tier, was challenging. The documentation often speaks in terms of project-level quotas or per-user quotas, which felt too broad for my situation. I was operating on a very lean setup, and the idea that I was somehow exceeding limits designed for much larger applications seemed unlikely, yet the error message was undeniable.

The breakthrough came when I started looking at the timing and pattern of the failures more closely, correlating them with my application's internal operations. I realized that the failures often occurred not during peak user activity, but during background tasks or internal processing jobs that ran on the same VM. These tasks, while not directly user-facing, were still making calls to Vertex AI.

The root cause, as it turned out, was a combination of factors:

Shared Resource Contention: My single VM was running both the web application serving users and background AI processing tasks. Both were sharing the same outbound IP address and the same API client configurations.
API Quota Granularity: Vertex AI's default quotas, while generous for many use cases, are still finite. Without explicit configuration for higher limits or a more robust quota management strategy, even a moderate number of concurrent requests from a single source could trigger the 429.
Lack of Backoff and Retry Logic: While I had some basic retry mechanisms, they weren't sophisticated enough to handle sustained rate limiting. They would retry too quickly, hitting the API again before the rate limit window had fully passed, thus perpetuating the problem.

The specific incident that forced me to address this was a critical background job for processing user-uploaded documents failing repeatedly. This job was essential for providing one of the core AI features of aicoreutility.com. Seeing it fail due to an external API's rate limit, especially when I felt my usage was reasonable, was frustrating.

The fix involved a multi-pronged approach:

Implementing Exponential Backoff with Jitter: I enhanced my API client to use a more robust exponential backoff strategy. When a 429 error is received, instead of retrying immediately, the client now waits an increasing amount of time before retrying, with a small random jitter added to prevent multiple instances from retrying at the exact same moment. This is crucial for respecting rate limits and allowing the API service to recover.
Request Throttling for Background Tasks: I introduced a separate, more conservative rate limiter specifically for my background processing jobs. This ensures that these non-critical, albeit important, tasks do not consume API resources in a way that impacts real-time user requests.
Monitoring and Alerting: I set up more granular monitoring for Vertex AI API error rates. If the 429 errors exceed a certain threshold within a given time window, I'm now alerted. This allows me to investigate proactively rather than discovering a service outage through user complaints.
Exploring Quota Adjustments: While not immediately implemented due to cost considerations on a small VM, I've bookmarked the process for requesting quota increases for Vertex AI if my usage continues to grow and these measures prove insufficient.

After implementing these changes, the 429 RESOURCE_EXHAUSTED errors significantly decreased. The background jobs now run reliably, and the core AI features remain available to users. It's a stark reminder that even with seemingly low usage, understanding and respecting external API rate limits is paramount, especially when operating on constrained infrastructure.

...building aicoreutility.com in the open... aicoreutility.com

TypeScript TS2802 Error: Resolving Observer Pattern 'Set' Spread with Array.from Conversion

박준희 — Fri, 12 Jun 2026 16:00:01 +0000

TypeScript Compile Error TS2802: Resolved with Observer Pattern by Converting Set Spread to Array.from

If you're stuck implementing the observer pattern due to TypeScript compile error TS2802, this post might help. I resolved the issue with a simple conversion: changing Set spread to Array.from().

Attempts and Pitfalls

While implementing the observer pattern, I encountered TypeScript compile error TS2802 when trying to spread a Set. Initially, I suspected the Set's type might be the problem, so I tried various approaches.

class Observer {
  private subscribers = new Set<() => void>();

  subscribe(callback: () => void) {
    this.subscribers.add(callback);
  }

  notify() {
    // TS2802 error occurs here
    for (const callback of [...this.subscribers]) {
      callback();
    }
  }
}

When attempting to spread the Set into an array using [...this.subscribers] as shown above, TypeScript failed to recognize it properly, throwing an error similar to TS2802: Cannot find module '...' or its corresponding type declarations.. At first, I thought it was a library configuration issue and spent a considerable amount of time lost.

The Cause

In the end, the problem lay with the Set spread syntax itself. When TypeScript applies the ... spread operator to a Set, there were instances where it couldn't accurately infer the types internally. This issue can be more pronounced in certain versions or environments.

The Solution

To resolve this, I used the method of explicitly converting the Set spread to an array using Array.from().

class Observer {
  private subscribers = new Set<() => void>();

  subscribe(callback: () => void) {
    this.subscribers.add(callback);
  }

  notify() {
    // Resolved by converting with Array.from
    for (const callback of Array.from(this.subscribers)) {
      callback();
    }
  }
}

By using Array.from(this.subscribers), TypeScript clearly recognizes the Set as an array, allowing the loop to execute correctly.

The Outcome

The TypeScript compile error TS2802 was cleanly resolved.
The observer pattern's notify method now functions as intended.
I no longer have to waste time on unnecessary type-related debugging.

Summary — To Avoid the Same Pitfall

[ ] If you encounter TS2802 errors when spreading a Set in TypeScript, try converting it with Array.from().
[ ] Instead of blindly following error messages, focus on specific parts of your code (in this case, the Set spread).
[ ] Before checking library configurations or type definitions, consider first improving the clarity of your code itself.