Reattempt of informer start() triggers all previous events

[jobcespedes]

Describe the bug
Redo informer start() triggers all previous events. This is being done inside setTimeout periodically as a workaround since informer silently stop receiving events (see: #596)

** Client Version **
1.0.0-rc4

** Server Version **
e.g. 1.26.5

To Reproduce

1. MakeInformer
2. Start informer
3. Set timeout starting informer in 30s
4. Trigger an update event in k8s for the informer to catch it
5. Wait for timeout to start informer again
6. See the update event in step 4 being reproduce again

Expected behavior
A clear and concise description of what you expected to happen.

** Example Code**

const timeoutDelay = 1000 * 30;
const timeout = setTimeout(() => {
  if (informer) {
    informer
      .start()
      .then(() => {
        console.log("Informer refresh connection");
      })
      .catch((err) => {
        console.log("Informer refresh error");
        console.error(err);
      });
  }
}, timeoutDelay);

Environment (please complete the following information):

• OS: linux
• NodeJS Version: v18.14.2
• Cloud runtime: EKS

Additional context
This is probably a secudary issue, being the primary that informer silently stop reproducing events, like in #596

[mstruebing]

I'm not an expert on how informers work but I guess this is because we have this data cached already and you do not instantiate a new one? As far as I know informers cache their data so it would make sense that they are replaying the events in case of a restart from my point of view.

As a workaround you could also try to save the last event you processed and skip until the event occurs and only process the newer ones?

Or can you try something like this and instantiate a new informer?:

const timeoutDelay = 1000 * 30;
let informer;
const timeout = setTimeout(() => {
    informer = ...; // instantiate a new informer
    informer
      .start()
      .then(() => {
        console.log("Informer refresh connection");
      })
      .catch((err) => {
        console.log("Informer refresh error");
        console.error(err);
      });
}, timeoutDelay);

[jobcespedes]

Hi @mstruebing,

Thank you for the suggestion. I thought about the option of starting a new informer. In this regard, I was wondering about the implications of not doing it correctly, reliably, and transparently, since the application using the informer cannot lose events. Another possible implication that I also wanted to avoid is memory leaks.

Regarding the mention of the cache, I also suspected that something has to do with the cache. I am reviewing the code in cache.ts to better understand what happens when using start(). I found the Bookmark option. According to the description, the functionality of the option could be used to avoid the current behavior. However, I believe it is not yet programmed in the informer.

The fact that the informer/watcher stops silently is also something that I would like to understand and avoid.

[mstruebing]

If you find the root cause why this is happening we are more than happy to accept PRs.

If the informer replays all your events you could save the last processed event, at least I believe the event + resourceVersion should be unique so you are sure you start processing at the right event in case of a restart.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.