DEV Community: Alkhassim Lawal Umar

The Sentry dashboard was empty for months — here's why (and the 2-line fix that mattered most)

Alkhassim Lawal Umar — Mon, 27 Jul 2026 09:08:40 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

This backend powers K-XpertAI, the AI coding assistant at the center of KingxTech's developer-tools ecosystem — a chat-first assistant that turns a prompt into working code in a live artifact panel, with SynthCode IDE as the editor you take it into next. The service in question is the Node/Express backend (internally kx-neurocore) that routes every chat turn across multiple model providers — Claude, Gemini, GPT, and a free open-weights tier — while also handling credits, billing, chat history, GitHub push/import, and per-project file storage. It runs on Google Cloud Run.

Bug Fix or Performance Improvement

TL;DR: Sentry had a valid DSN, was fully configured, and still saw nothing. Zero errors, zero transactions, for months. The DSN wasn't the problem — 18 routes silently never told it anything was wrong.

I went looking for why the dashboard was a ghost town, and traced it to one line of asymmetry in the code: only one route out of nineteen ever called Sentry.captureException(). Everything else — billing checkout, credit checks, chat sessions, chat history, GitHub push/import, project file reads/writes — caught its own errors and quietly did console.error(...), then returned a clean JSON error to the client. Functionally fine for the user. Invisible to Sentry.

That's the dangerous kind of bug: nothing crashes, nothing 500s in a way anyone notices, the app "works." But the one signal that would have told me a Paystack checkout was failing, or a GitHub push was silently erroring for a specific user, never left stdout. Whatever was actually breaking in production was a total blind spot.

NODE-1 — the first issue ever recorded in this Sentry project, captured seconds after deploying the fix.

Code

fix: Sentry error reporting gap across API routes #1

KingzAlkhasim posted on Jul 26, 2026

Sentry was correctly configured with a valid DSN, but the project dashboard showed zero transactions and zero errors, even in production. Digging through the codebase, I found the actual cause: only one route (/api/ai/generate) called Sentry.captureException(). Every other route — 18 of them, covering billing, credits, sessions, chat history, GitHub integration, and project file operations — only did console.error(...). Errors on those routes were logged to stdout and then simply vanished; Sentry never saw them at all.

This meant that whatever was actually breaking for real users — a failed Paystack checkout, a broken GitHub push, a corrupted session — was completely invisible in Sentry, no matter how well-configured the DSN was.

My Improvements

Rather than adding a one-off Sentry.captureException() call at each of the 18 sites individually, I centralized the fix:

13 of the 18 routes already funneled their errors through a shared handleFsError() helper — I fixed the instrumentation gap there once, which covered all 13 in a single change. The remaining 5 routes built their own status codes/messages, so I added a small reportError() helper with the same signature and reused it across those. Both helpers use the identical await Sentry.flush(2000).catch(() => {}) pattern that the one correctly-instrumented route already had — this matters specifically on Cloud Run, which freezes a container's CPU immediately after the HTTP response is sent. Sentry delivers events asynchronously in the background, so without an explicit flush before the response ends, a scaled-down instance can silently drop the event mid-delivery. I also added a one-line startup log ([sentry] initialized / [sentry] disabled — SENTRY_DSN not set) — previously there was no way to tell from Cloud Run's logs whether Sentry had actually picked up the DSN on a given deploy.

Typechecked clean against the existing tsconfig.json with no other behavior changes — every route still returns the same status codes and error messages to the client; the only difference is that unexpected errors now actually reach Sentry.

View on GitHub

My Improvements

Instead of bolting Sentry.captureException() onto all 18 catch blocks one by one, I collapsed the fix into two places:

13 of the 18 already funneled through one shared handleFsError() helper — fixing the gap there covered all 13 routes in a single change.
The remaining 5 built their own status codes and messages, so I extracted a small reportError() helper with the same shape and swapped them over.
Both helpers share the exact await Sentry.flush(2000).catch(() => {}) pattern the one correctly-instrumented route already had — and that flush isn't decorative. Cloud Run freezes a container's CPU the instant the HTTP response is sent. Sentry ships events asynchronously in the background, so a fire-and-forget captureException() is racing against the container being frozen mid-delivery. Skip the flush, and even a correctly called Sentry report can vanish.
I also added one line at startup — [sentry] initialized or [sentry] disabled — SENTRY_DSN not set — because there was previously no way to tell from Cloud Run's logs whether Sentry had even picked up the DSN on a given deploy. The exact class of bug I'd just spent an afternoon hunting down would have taken thirty seconds to diagnose with that log line in place.

Before — every route silently swallowed its own errors:

function handleFsError(res: express.Response, error: unknown) {
  if (error instanceof ProjectAccessError) {
    res.status(403).json({ success: false, error: error.message });
    return;
  }
  console.error('Project FS error:', error);
  res.status(500).json({ success: false, error: 'Internal error.' });
}

} catch (error) {
  console.error('Request cap check error:', error);
  res.status(500).json({ success: false, error: 'Failed to check model usage limit' });
  return;
}

After — the same two shared helpers, actually reporting to Sentry with the Cloud-Run-safe flush:

async function handleFsError(res: express.Response, error: unknown) {
  if (error instanceof ProjectAccessError) {
    // Expected access-control rejection, not a bug — no Sentry report.
    res.status(403).json({ success: false, error: error.message });
    return;
  }
  console.error('Project FS error:', error);
  Sentry.captureException(error, { tags: { route: res.req?.path } });
  // Cloud Run can freeze/scale an instance down right after the response is
  // sent, and Sentry delivers events asynchronously in the background —
  // without this flush, errors on a scaled-down instance can silently never
  // reach Sentry at all. 2s cap so a slow network never hangs the response.
  await Sentry.flush(2000).catch(() => {});
  res.status(500).json({ success: false, error: 'Internal error.' });
}

// Same reporting + flush pattern as handleFsError, for routes that build
// their own status code / message instead of the generic "Internal error."
async function reportError(
  res: express.Response,
  status: number,
  message: string,
  error: unknown,
  logLabel: string
) {
  console.error(logLabel, error);
  Sentry.captureException(error, { tags: { route: res.req?.path } });
  await Sentry.flush(2000).catch(() => {});
  res.status(status).json({ success: false, error: message });
}

} catch (error) {
  await reportError(res, 500, 'Failed to check model usage limit', error, 'Request cap check error:');
  return;
}

And the startup visibility fix, in lib/sentry.ts:

export function initSentry(): void {
  const dsn = process.env.SENTRY_DSN;
  if (!dsn) {
    console.log('[sentry] disabled — SENTRY_DSN not set');
    return;
  }

  Sentry.init({
    dsn,
    tracesSampleRate: 1.0,
    sendDefaultPii: false,
  });
  console.log('[sentry] initialized');
}

Typechecked clean against the project's existing tsconfig.json. Zero behavior change from the client's point of view — same status codes, same error messages. The only difference: every error the API actually hits now has a chance of reaching Sentry instead of none.

Best Use of Sentry

The core insight here isn't "add more captureException calls" — it's that Sentry's async delivery model and Cloud Run's freeze-after-response model are directly in tension, and the fix has to account for both at once:

Flush before you finish — await Sentry.flush(2000) in a finally block, capped at 2 seconds so a slow network never hangs a real user's response, is the difference between "Sentry looks configured" and "Sentry actually receives events" on any serverless/scale-to-zero platform.
Instrument by construction, not by memory — routing every route's error handling through two small shared helpers means the next route added to this API gets Sentry coverage automatically, instead of depending on someone remembering to add it.
Make init state visible — a one-line startup log turns "is Sentry even working right now?" from a guessing game into something you read off the Cloud Run logs in seconds.

The Missing GitHub Icon That Broke My Production Build

Alkhassim Lawal Umar — Fri, 24 Jul 2026 19:19:48 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setup

I'm building KingxTech, and specifically K-XpertAI — an AI agent that reads, writes, and deletes files in a live project workspace, then hosts the result instantly. Under the hood it's a React 19 + Vite frontend talking to a TypeScript/Express backend on Cloud Run.

I'd just shipped a big batch of changes to the workspace UI — a proper code editor, a file tree with GitHub import/export buttons, a terminal tab. Pushed to GitHub, Vercel kicked off the deploy... and it failed.

The bug

Error: Command "npm run build" exited with 1

Digging into the build log, the real error was buried a few lines down:

15 │ import { File as FileIcon, Folder, FolderPlus, FilePlus, Trash2, Save,
   │   RefreshCw, Undo2, Copy, ExternalLink, Code2, Eye, Rocket,
   │   TerminalSquare, Upload, Maximize2, Minimize2, Github, FolderInput,
   │   SlidersHorizontal, Info, Plus } from "lucide-react";
   │ ───┬──
   │ ╰──── Missing export

Vite's bundler (via Rolldown) was telling me Github didn't exist as an export in lucide-react — but only in Vercel's build. It worked fine in local dev. That's the kind of bug that makes you doubt your own eyes: the icon was clearly imported the same way as a dozen others on that same line that worked perfectly.

The investigation

First instinct: check the installed version.

"lucide-react": "^1.23.0"

Nothing obviously wrong there. So instead of guessing at what icon names should exist, I installed that exact version in an isolated sandbox and just asked the module directly:

const icons = require('lucide-react');
const names = ['Github', 'FolderInput', 'SlidersHorizontal', /* ...the rest */];
for (const n of names) {
  console.log(n, typeof icons[n] !== 'undefined' ? 'OK' : 'MISSING');
}

Github MISSING
FolderInput OK
SlidersHorizontal OK
...everything else OK

There it was. Every icon in that import worked except Github.

The root cause

lucide-react — like a lot of modern icon libraries — has been progressively removing brand/trademark logos (GitHub, Twitter, etc.) from its default export set, pushing people toward dedicated brand-icon packages instead. Somewhere between versions, the plain Github icon quietly stopped being exported. Local dev didn't catch it because of caching in node_modules from an earlier install; a clean Vercel build (fresh npm install every time) surfaced it immediately.

The fix wasn't "install a different package" — it was small enough to just inline:

// Before: relying on a brand icon that no longer ships
import { Github } from 'lucide-react';

// After: a tiny local SVG component instead
function Github({ size = 14 }) {
  return (
    <svg width={size} height={size} viewBox="0 0 24 24" fill="currentColor">
      <path d="M12 .5C5.7.5.5 5.7.5 12c0 5.1 3.3 9.4 7.9 10.9..." />
    </svg>
  );
}

Same component name, same usage everywhere else in the file — zero call-site changes needed.

Verifying it, not just eyeballing it

Since the whole failure was "works locally, fails in CI," I didn't trust a visual read of the diff. I ran the actual production build in a clean environment:

npm install
npm run build

✓ 1902 modules transformed.
dist/index.html                     1.44 kB
dist/assets/index-*.css            24.68 kB
dist/assets/index-*.js           1,185.88 kB
✓ built in 3.16s

Clean exit code, real dist/ output. Only then did I consider it actually fixed.

What I'm taking away

A missing export is a build-time contract violation, not a typo — treat it like one. Don't guess at what a package should export; ask it.
Local dev green ≠ CI green. Stale node_modules can hide exactly this class of bug. A clean install is the only honest test.
Brand icons in open-source icon libraries are not guaranteed to stay. If your UI depends on a company's logo shape, either pin the package version deliberately or just own a tiny inline SVG — it's one function, and it never breaks on you again.

Small bug, but a good reminder that "it built yesterday" is not evidence of anything today.

Building an AI-Native Development Platform: What's New in KingxTech

Alkhassim Lawal Umar — Sun, 19 Jul 2026 13:21:34 +0000

Building an AI-Native Development Platform: What's New in KingxTech

How I went from an AI chat interface to an autonomous development workflow.

Over the past few months, I've been building KingxTech—an AI-native platform for developers. The goal isn't just to add AI to an editor; it's to create a workflow where planning, coding, version control, publishing, and deployment happen in one place.

This latest update is one of the biggest milestones so far.

🤖 A Better AI Workflow

One thing that always bothered me about AI coding tools is that they often jump straight into editing files.

I wanted K-XpertAI to work more like a teammate.

Now the workflow looks like this:
You describe what you want to build.
K-XpertAI analyzes the request.
It presents an implementation plan.
You choose Accept or Reject.
The AI applies the changes.
You can Undo any edit if needed.

The goal is to keep developers in control while still benefiting from AI automation.

⚡ Live Agent Progress

Instead of a generic *"Thinking..." * message, the AI now streams its progress live.

You'll see updates such as:

Reading project files
Running commands
Building components
Editing files
Cleaning up

Watching the agent work makes the process much easier to follow.

🧠 Multiple AI Models

K-XpertAI now supports choosing different models for different tasks.

Examples:

`:G-flash/ Explain this code

:C-sonnet/ Refactor this project

:O-terra/ Optimize performance`

For everyday development, there's also a free default model available without consuming monthly credits.

📊 Credits That Make Sense

Free users now receive 300 AI credits every month.

Premium models consume different amounts depending on their capability, while the default free model remains available for basic coding assistance.

The Console also includes a complete usage history so developers can track how their credits are being used.

🚀 GitHub Integration

One of my favorite additions is GitHub integration.

The workflow is simple:

Generate a Personal Access Token.
Connect it to your KingxTech account.
Push your project directly from the workspace .

No switching between multiple applications.

🌐 One-Click Publishing

Projects can now be published directly from the workspace.

Instead of sharing a long project ID, each published project receives a cleaner permanent URL.

Custom domain support is also built into the workflow by generating the required DNS records.

💻 Built-in Terminal

A new Terminal tab lets developers run safe commands directly inside the workspace.

This keeps common development tasks close to the editor instead of requiring another terminal window.

📈 Why I'm Building This

My goal isn't to create another AI chatbot.

I'm trying to build a developer platform where AI naturally fits into the software development lifecycle.

That includes:

Authentication
AI assistance
Project workspaces
Version control
Publishing
Domains
Cloud infrastructure

...working together as one experience.

What's Next

I'm currently working on:
Better multi-model routing
Richer project previews
Improved AI planning
Cloud integration
More developer tooling

There's still a lot to build, but this update feels like a major step toward the platform I originally imagined.

If you're interested in AI-assisted software development, I'd love to hear your thoughts and feedback.

Website: https://kingxtech.name.ng

GitHub: https://github.com/KingzTechCompy

Building K-xpertAI: A Developer Assistant Powered by KX-NeuroCore & Gemma 4

Alkhassim Lawal Umar — Sat, 16 May 2026 23:20:02 +0000

## Introduction
At KingxTech, the goal is to build a complete AI ecosystem for developers — tools that help programmers debug, build, and plan projects more efficiently.

The first major step in that vision is K-xpertAI, a developer-focused AI assistant designed for coding support, deployment troubleshooting, and architecture planning.

The Tech Stack

Model

Google Gemma 4 (26B)
Chosen for its advanced reasoning, extensive coding knowledge, and low-latency technical responses. The 26B parameter model provides the perfect balance between high-level logic and processing speed.

Engine: KX-NeuroCore (Logic Layer)

The custom logic layer responsible for:

Context Optimization: Managing memory efficiency.
Response Control: Shaping raw AI output into developer-ready advice.
Smart Processing: Handling complex request routing.

Backend: Netlify Serverless

Powered by Node.js and Netlify Functions. Using a serverless architecture allowed for rapid deployment and automatic scaling without the overhead of traditional server management.

Frontend: NeuroCore UI

A custom HTML/CSS interface focused on a futuristic, high-contrast aesthetic. It features a terminal-inspired layout, JetBrains Mono typography, and high-performance rendering to match a developer's fast-paced workflow.

The Challenge: The “Scrubber” System

One of the primary challenges during development was optimizing the model’s raw Chain of Thought (CoT) output for a production UI.
Gemma 4 is highly analytical, often outputting its internal planning and validation steps. While useful for the AI, this "noise" can clutter a clean user interface. To solve this, I built a custom Scrubber System that:

Regex Filtering: Strips internal metadata headers and self-evaluation checklists.
Noise Reduction: Removes unnecessary reasoning fragments.
Formatting Preservation: Ensures that code blocks and technical explanations remain intact while removing the "meta" chatter. This makes K-xpertAI feel faster, cleaner, and more like a production-ready engineering tool.

Performance Optimization

Context Windowing

To maintain high response speeds and token efficiency, I implemented Context Slicing (history.slice(-4)). This ensures the model stays hyper-focused on the current technical task while maintaining enough memory to understand the conversation flow.

Temperature Tuning

I tuned the model temperature to 0.7. Through testing, this proved to be the "sweet spot" for developers — high enough to provide creative architectural solutions, but low enough to maintain strict technical accuracy for debugging and code generation.

Real-World Use Cases

K-xpertAI is built for practical engineering workflows:

Deployment Debugging: Specialized logic for resolving Netlify 500 errors and environment configuration issues.
Full-Stack Assistance: Expert-level help with JavaScript, Node.js, and modern framework architecture.
System Design: Planning scalable backend structures and API integrations.

Conclusion

K-xpertAI is the foundation of the larger KingxTech AI ecosystem. By combining the power of Gemma 4, the scalability of Netlify, and the custom optimization of KX-NeuroCore, we've created a tool that bridges the gap between raw AI potential and real-world engineering needs.

This is just the beginning of the KingxTech journey.

Live Demo: https://kxpertai.netlify.app/
- GitHub Repository:. https://github.com/KingzAlkhasim/K-Xpert

How to Fine-Tune a Llama Model on Hugging Face Using Python

Alkhassim Lawal Umar — Fri, 08 May 2026 22:30:59 +0000

Introduction: Why Is This Topic Important?

Large Language Models (LLMs) like Llama by Meta AI have changed the way developers build AI applications. Instead of creating models from scratch, developers can now fine-tune existing models for specific tasks such as chatbots, coding assistants, summarization tools, or customer support systems.
Fine-tuning is important because a pre-trained model already understands language patterns, but it may not understand your specific use case. By training the model on your own dataset, you can make it respond in a more accurate and specialized way.
Thanks to Hugging Face and Python libraries like Transformers, the process has become much easier than it used to be. With only a few lines of code, developers can load a Llama model, prepare a dataset, and start training.
In this article, we will walk through the full process step by step in a simple and practical way.

The Setup: Installing the Required Libraries

Before we start training the model, we need to install the required Python libraries. Open your terminal or command prompt and run:

pip install transformers datasets accelerate peft trl torch

Here is what each library does:

transformers: Used for loading and working with Llama models.
datasets: Helps us load and manage training datasets.
accelerate: Makes training faster and easier on GPUs.
peft: Allows parameter-efficient fine-tuning techniques like LoRA.
trl: Provides training utilities for language models (Post-Training).
torch: The main deep learning framework used by Hugging Face. ### The Core: Fine-Tuning Step by Step #### Step 1: Import the Required Modules The first thing we do is import the libraries we need into our Python script.

from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments
from datasets import load_dataset
from trl import SFTTrainer

AutoTokenizer: Converts text into tokens that the model understands.
AutoModelForCausalLM: Loads the Llama language model.
TrainingArguments: Stores your specific training settings.
load_dataset: Pulls datasets directly from the Hugging Face Hub.
SFTTrainer: Handles the heavy lifting of Supervised Fine-Tuning. #### Step 2: Load the Llama Model Now we load the tokenizer and the model weights.

model_name = "meta-llama/Llama-3-8B"

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

Note: You need access permission for Meta's Llama models on Hugging Face before downloading them. Ensure you are logged in using huggingface-cli login. #### Step 3: Load a Dataset Next, we load a dataset for training. For this example, we’ll use a subset of movie reviews.

dataset = load_dataset("imdb", split="train[:1000]")

split="train[:1000]" loads only the first 1000 examples. Smaller datasets are useful for testing your code before committing to a full training run. #### Step 4: Configure the Tokenizer Some Llama models require a padding token to handle batches of text.

tokenizer.pad_token = tokenizer.eos_token

Why is this necessary? Models process text in batches. Short sentences need "padding" so all inputs have the same length. We use the end-of-sequence (EOS) token to fill that space.

Step 5: Set Training Arguments

Now we define the configuration for our training "engine."

training_args = TrainingArguments(
    output_dir="./llama-finetuned",
    per_device_train_batch_size=2,
    num_train_epochs=1,
    logging_steps=10,
    save_steps=50
)

output_dir: The folder where your results will live.
per_device_train_batch_size: Set to 2 to avoid running out of GPU memory (VRAM).
num_train_epochs: How many times the model sees the entire dataset. #### Step 6: Create the Trainer We connect the model, the data, and the settings together.

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    args=training_args
)

Instead of manually writing a complex training loop, the SFTTrainer automates backpropagation and weight updates for us.

Step 7: Start Fine-Tuning

This is the moment of truth. Run the following command to start the engine:

trainer.train()

During this stage, the model reads the text, predicts the next word, calculates the error, and updates itself to become more accurate for your specific data.

Step 8: Save Your Work

Once training is complete, save the fine-tuned weights so you can use them in your apps.

trainer.save_model("./final-llama-model")

The Conclusion: What Did We Learn?

In this article, we covered the essential workflow for adapting a state-of-the-art model to your needs. We learned how to:

Prepare the environment with specialized AI libraries.
Load gated models from Meta and Hugging Face.
Configure training parameters like batch size and epochs.
Save and export a specialized model. What's Next? As you continue your journey, I recommend exploring LoRA (Low-Rank Adaptation) and Quantization. These techniques allow you to fine-tune massive models on much cheaper hardware, which is a game-changer for independent developers and startups.

About the Author:
I am a Full-Stack Developer and UI/UX Designer dedicated to building the next generation of tech tools. Through KingxTech, I develop everything from professional IDEs to custom AI models like KX-NeuroCore. My focus is on technical clarity and performance, ensuring that the intersection of web development and AI is powerful, efficient, and open to all.