dependabot[bot] on npm_and_yarn
chore(deps): bump debug and moc… (compare)
dependabot[bot] on npm_and_yarn
chore(deps): bump json5 from 1.… (compare)
dependabot[bot] on npm_and_yarn
chore(deps): bump json5, ts-loa… (compare)
dependabot[bot] on npm_and_yarn
chore(deps): bump express from … (compare)
dependabot[bot] on npm_and_yarn
chore(deps): bump decode-uri-co… (compare)
dependabot[bot] on npm_and_yarn
chore(deps): bump qs from 6.2.1… (compare)
dependabot[bot] on npm_and_yarn
chore(deps): bump loader-utils … (compare)
QueueScheduler
usage in redux-observable@2 with rxjsw@7. We do some heavy subject usage in our codebase (some ReplaySubject(1)
in deps
, among others), although we avoid at maximum explicit subscribe
s and try to leave everything for the global subscription. Nonetheless, it seems QueueAction
s are pilling up and clogging memory heavily. We checked and it seems subscriptions are not leaking (all subjects's observers
, including internal redux-observables subjects, are constant in number), but QueueAction, and observeOn's OperatorSubscriber
s instances makes our memory usage skyrocket, and these actions are not freed. Most of it seems to be references in _teardowns
. Removing queueScheduler
usage on redux-observable makes the problem disappear, but it may be triggered by something we do. Does anyone have experience with this kind of issue? If not, I may try to prepare a self-contained repro to open an issue
`import type { Epic } from 'redux-observable';
import { filter, mapTo,map } from 'rxjs/Operators';
export const demoEpic: Epic<any,any,any,any>= (action$,state )=>{
console.log(action$)
return action$.pipe<any,any>(
filter<any,any>((v:any)=>{
return false
}),
mapTo({type: '1231'})
)
}`