I Built My Own Error Tracker

Ildar Timerbaev — Wed, 22 Jul 2026 10:58:11 +0000

Every production application eventually crashes. I don’t mind runtime errors. What I do mind is spending hours trying to understand what actually happened. There are many different tools, services, and SaaS platforms that can help with it. The problem is that many of them have become incredibly complex.

As a senior engineer, I care not only about convenience, but also about performance, security, and privacy. That motivated me to explore the idea of building my own error-tracking platform.

The challenge

Every engineer can imagine dozens of features for a new project. I
didn’t want to drown in an endless feature loop. I wanted to ship something useful as quickly as possible. And I didn’t want another endless stream of events. Then I asked myself one simple question:

What do I actually need right now?

The answer was easy:

I want to catch production errors without digging through a stream of raw events. There should be an entity that groups related events into a single issue.

Solution

I decided to keep the SDK tiny. It is written in TypeScript and has zero dependencies. The backend runs on Kotlin + Spring Boot, while the dashboard is built with SolidJS.

Everything revolves around issues. An issue is an entity built from related events. Each event contains information about the error and its environment: stack trace, metadata, URL, etc. (without collecting sensitive information). The system calculates the fingerprint of the error and either creates a new issue or finds an existing one, then attaches the event to it. That’s it.

The magic happens later. Once the system has collected the data, it needs to present it in a useful way. I solved this with AI summaries. The AI agent knows everything about the issue and generates a human-readable summary that helps not only developers but also managers understand the problem. The result is an issue page with all the technical details and a concise summary that helps explain what happened and what impact it may have on the product.

After implementing this, I discovered another problem: having to open the dashboard just to check the project status. The solution was simple, I created a generic integration module for Telegram and our internal company messenger. Now it pushes new and regressed issues, along with AI summaries, directly to the tools the team already uses, so you know about problems instantly.

Trade-offs

At this point, the project had become an issue-centric tracking platform. I decided to share it publicly, but soon faced one serious problem. Let’s deep dive.

Database boundaries

Unfortunately, a database doesn’t have infinite storage. I had to decide how to keep the event stream clean and fresh. The idea was simple: keep only recent events. If an event hasn’t appeared for a while, the issue has probably been fixed or no longer occurs. I chose a simple FIFO retention strategy: no more than 100,000 events per project over a rolling 7-day window. It solved the problem.

Instead of a conclusion. RetraceKit is still evolving. There are many things I want to improve, but today it already solves the problem that made me build it in the first place. If you decide to give it a try, I’d genuinely love to hear your feedback: what feels useful, what doesn’t, and what you’d improve.

Platform: https://retracekit.cloud

Support on ProductHunt: https://www.producthunt.com/products/retracekit-error-tracking-platform

React query for data streaming

Ildar Timerbaev — Mon, 27 Nov 2023 09:22:46 +0000

Introduction

Everyone is familiar with the popular framework for managing API requests — @tanstack/react-query. This framework is designed for handling browser HTTP API requests. However, that’s not the only way to use it. React query also supports any promises within queries and mutations, which assists us in setting up data streaming and react query together. Let’s get started!

Theory

Client setup

Since We want to handle data streaming then We assume to use a some kind of WebSocket with STOMP for it. Let’s imagine that We have very simple data flow.

const stompClient = new StompClient()
stompClient.subscribe((event) => {...})
stompClient.publish('mychannel, {...})

To gain access from any part of our application, we should position this client within the React context, which will be provided in the root component. Currently, this context will only contain a client instance for accessing our queries and mutations.

const StompContext = createContext({
 client: undefined
})

function StompManager({ children }: PropsWithChildren) {
 const [client, setClient] = useState(new StompClient())

 return <StompContext.Provider value={{ client }}>{children}</StompContext.Provider>
}

function useStompManager() {
 const { client } = useContext(StompContext)
 return client
}

Query

Let’s revisit how queries work. They consist of an identification key, a query function, and options. Since the identification key is self-explanatory, we’ll focus on the query function and options.

Firstly, each query should only be activated when our client is ready.

const client = useStompManager()
...
useQuery([QueryKey], () => {...}, { enabled: !!client })

Secondly, each query requires a function to subscribe to the channel and wait for new data. There are several different subscription types:

One event subscription — This is a pattern where we receive something from the channel and then complete the subscription (e.g., getting a user profile).
Infinite event subscription — This is a pattern where we listen to the channel until it’s unsubscribed or cancelled (e.g., listening to chat messages). Each subscription should be stored in a subscriptions storage to avoid generating multiple subscriptions on each query call.

Since we may have infinite queries, we need to create a subscriptions storage in the StompContext. For this, I'll use the useMap hook from the react-use package. Let's establish a rule that the subscription identifier is the query key.

const [subscribers, { set, get }] = useMap<Record<string, boolean>>();

Mutation

The implementation of mutations can vary depending on the protocol used. For instance, chat messages could return a sent message in a channel, indicating successful transmission. However, this is a unique case. Suppose the STOMP client has a publish method that returns a promise. In that case, this mutation doesn't have any specific logic.

function useStompMutation(mutationKey: string, destination: string) {
  // getting client
  // default useMutation hook with sending the message in mutation function
}

Sending without confirmation

function useStompConfirmableMutation(mutationKey: string, channel: string, destination: string) {
  // getting client
  // default useMutation hook with next mutation function:
  // 0. Return the promise with resolve, reject parameters
  // 1. Subscribing to specific channel and resolving the promise there
  // 2. Sending a message based on mutation function parameters
  // 3. Handling error to reject the promise
}

Sending with confirmation

Implementation

One event query

function listenOnce(client: StompClient, channel: string) {
 return new Promise((resolve, reject) => {
 const sub = client.subscribe(channel, event => {
   sub.unsubscribe()
   resolve(event)
  })
 })
}

function useStompQuery<DATA, ERROR>(
 queryKey: QueryKey, 
 channel: string,
 options?: UseQueryOptions<DATA, ERROR>
) {
 const client = useStompClient()
 return useQuery(
  queryKey, 
  async () => listenOnce(),
  {
   ...options,
   enabled: !!client && (options?.enabled ?? true),
  }
}

Infinite events query

function useStompQuery<DATA, ERROR>(
 queryKey: QueryKey, 
 channel: string,
 newDataResolver: (previousData: DATA[], newComingData: DATA) => void,
 options?: UseQueryOptions<DATA[], ERROR>,
) {
 const client = useStompClient()
 const { setSubscriber, getSubscriber } = useContext(StompContext)
 const queryClient = useQueryClient()

 // Hook from react-use package
 useMount(() => {
  if (getSubscriber(queryKey)) {
   return
  }

  const sub = client.subscribe(channel, event => {
   const previousData = queryClient.getQueryData<DATA[]>(queryKey)
   let nextData = newDataResolver(previousData, event)
   queryClient.setQueryData(queryKey, nextData)
  })
  setSubscriber(queryKey, sub)
  })

 return useQuery<DATA[]>(
  queryKey,
  () => queryClient.getQueryData<DATA[]>(queryKey),
  {
   ...options,
   enabled: !!client && (options?.enabled ?? true),
  }
}

Let’s highlight an implementation details:

newDataResolver – special mutating function that allow us to control each new event coming(e.g. whenever new message coming then We could mark it with sent status);
() => queryClient.getQueryData<DATA[]>(queryKey) – as this query hasn’t one-time fetching function then We have to return the query itself data on each refetch.

Mutation without confirmation

function useStompMutation<T, DATA>(
 mutationKey: string, 
 destination: string,
 options?: UseMutationOptions<DATA>
) {
 const client = useStompClient()
 return useMutation<DATA>(
  mutationKey, 
  async (message: T) => {
   if (!client) {
    throw new Error('Client not found')
   }
   client.publish(destination, message)
  },
  options
 ) 
}

Mutation with confirmation

function useStompConfirmableMutation<T, DATA>(
 mutationKey: string, 
 destination: string,
 channel: string,
 confirmation?: (event: DATA) => boolean,
 options?: UseMutationOptions<DATA>
) {
 const client = useStompClient()
 return useMutation<DATA>(
  mutationKey, 
  async (message: T) => new Promise(async (resolve, reject) => {
   if (!client) {
    throw new Error('Client not found')
   }

   client.subscribe(channel, event => {
    if (confirmation(event)) {
     resolve(event)
    }
   })

   try {
    await client.publish(destination, message)
   } catch (e) {
    reject(e)
   }
  }),
  options
 ) 
}

The potential issue here is that if the event doesn’t return in the channel, it may cause an infinite promise. Implementing timeout rejection could resolve this, but I’ll leave that up to you 🙂

Conclusion

We’ve successfully implemented a working solution for data streaming in React Query. However, this solution may not be ideal for all use-cases, so you might need to adjust it depending on your data streaming service implementation.

Thank you for reading!

Source: Own article on Medium

DEV Community: Ildar Timerbaev