Concurrent Mode

Do you want to request a feature or report a bug?
Feature
What is the expected behavior?
Full compatibility with Concurrent Mode
Details
We should be close to a Concurrent Mode release, and people are already experimenting with it on their projects. I am not sure but it seems react-redux is not compatible yet, based on this tweet and this pr.

There's still not ETA on when Concurrent Mode will be released, and there's also a general lack of clarity on what exactly it will include, what the impacts are, and what the points of incompatibility may be.
As Dan said in issue #1164:

We need to be clear that there are several “levels” of compatibility with new features of React. They’re not formalized anywhere yet but a rough sketch for a library or technique X could be:

X breaks in sync mode
X works in sync mode but breaks in concurrent mode
X works in concurrent mode but limits its DX and UX benefits for the whole app
X works in concurrent mode but limits its UX benefits for the whole app
X works in concurrent mode but limits its DX and UX benefits for features written in X
X works in concurrent mode but limits its UX benefits for features written in X
X works in concurrent mode and lets its users take full advantage of its benefits

This is not a strict progression and there’s a spectrum of tradeoffs. (For example, maybe there is some temporary visual inconsistencies such as different like counts, but no crashes are guaranteed.)

But we need to be more precise about where React Redux is, and where it aims to be.

Until Concurrent Mode is actually out and completely documented, we can really only speculate on the potential interactions, and there's a lot of other stuff that I'd rather spend my time worrying about.
I'll leave this open as a placeholder, but it's not an immediate priority.

I don't mean any rush, but while it's not an immediate priority, let's do some experiment.
I made a small repo for reproduction of "tearing" (as far as I understand).
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode
It would be nice if someone could review it as I might be biased.
Please file issues there about this tool or any related discussion, not to disturb this issue here.

Hello redux team,
We were just wondering if there are any updated guidelines or at least high-level predictions on building components libraries on top of react-redux and making sure, to the best knowledge available, they will play nicely with concurrent mode?
We have switched fully to hooks version with useSelector for reading data and useDispatch for writing. We are also making sure that we do not do any side effects during rendering, i.e. all the dispatches are done inside useEffect. To be honest - just this - to only dispatch inside useEffect - has resulted in complete refactoring of entire codebase. Since its been a few months that this issue was opened, it would be great to get some more feedback from the team about the future.
Thanks for your hard work!

@gcloeval: nope, no further updates, because there's no new info available on Concurrent Mode.
Realistically, I expect React-Redux won't be "compatible", in the sense that folks expect store updates to be readable immediately. That said, it may not be a blocker from using Concurrent Mode.

@markerikson now we have updates on concurrent mode could we see a future of this?

The short version is that it's going to be up to the community to experiment and see exactly where the incompatibilities are.  I don't currently have time to look into it myself, and I don't have enough experience doing data fetching to work with most of the  concepts that are described.
As an example, Dan told me that Suspense transitions would likely be problematic, because you'd end up with cases where the Redux store is already updated from a dispatched action and thus trying to display "new" UI, whereas Suspense would want to still be displaying "old" UI.
Dan has strongly recommended trying to duplicate some of the Suspense/CM demos with Redux.  Someone on Reactiflux was trying to do a bit of that the other day, and I'll see if I can paste in their comments.

Hi folks.
My idea is to change forceRender into useSelector hook, let instead set a state, and return that state.
This should transform redux state changes into react useState changes that should batched and eventually paused form react concurrent mode useTransition.

@salvoravida : if you've got ideas, please feel free to prototype them and see how they work out.
That said, I'm not sure how what you're describing is actually different than what we do right now internally, and it doesn't change the issue that there's going to be differences between what the Redux store says is the "current" state value, and what React is currently wanting to display based on Suspense changes.

The "tearing" issue is .. expected. At least within Suspense.

Suspense just tells to display a fallback UI if some component is waiting for some data to be "ready"
useTransition (startTransition), tells Suspense to keep the old UI visible for a specific time (setup with { timeoutMs })

If the old UI needs to display "current" data, then it's a blocking-update and React will warn about it with or without using Redux. So the point is to "bake" useTransition within your components (as suggested in docs). Within a transition, it basically tells React to update the new UI (that is in memory and not displayed yet).
The mechanism is pretty simple actually. This is what tells Suspense to .. suspend the UI:
const MyComponent = () => throw { then(tellSuspenseThatWeAreReadyForNewUI, fail) {} }
const App = () => {
  return (
    <Suspense fallback="New UI not ready">
       <MyComponent />
    </Suspense>
  )
}

So, the main issue I think is .. what to throw 🙈 and how/if react-redux can help with that or if it needs to be implemented on user side.
This is a very naive implementation:
const promise = { // throw this instead
  then(tellSuspenceToContinue, throwAnError) {
    const unsubscribe = store.subscribe(() => {
      if (store.getState() !== STATUS.PENDING) {
        ubsubscribe();
        tellSuspenceToContinue();
      }
    });
  }
};

Here is a sandbox which describes what I mentioned above:
https://codesandbox.io/s/peaceful-spence-yh8w7
It shows the differences with/without useTransition (check console)
A complete separate issue is tearing that is not related to "intentional transition/suspense tearing" that could happen when nested components render too slow. However, I don't know if this is a bug or not. I found out that some slow renders are never committed to the DOM, so I'm just waiting for a more .. stable - experimental release 🙈 to know if it's really a thing to worry about or not. Currently happens because of nested Providers with react-redux. However, I haven't tried using react-redux hooks. I suspect that the issue shouldn't be if there are no connected components and just hooks but I haven't really had the time to test that.

Related issue: https://github.com/JustSift/ReSift/issues/32

@eddyw i can't see any unexpected behavior in your demo.
on StoreState changes -> useState.setState
within startTransition  setState delay 5000ms so you will see correctly old UI until "Loading".
that's the correct behavior.
if after startTransition, storeState changes many times it will enqueue setState manu time.
after trantion end due to 5000ms timeout or promiseResolve (Suspense end transition on promise resolve) all pending setState will be batched executed and you will see on Screen only last
"reduxStore" update.
that's fine.
Am i missing something?

We're having a good discussion with Dan atm on Twitter about whether it would be helpful for the React team to try porting a couple of the Suspense demos to Redux to show what's broken, and and how we might be able to understand the issues involved.
A few entry points into the subthreads (read up and down from these links):
https://twitter.com/dan_abramov/status/1192569023529140231
https://twitter.com/dan_abramov/status/1192570534543933441
https://twitter.com/EphemeralCircle/status/1192574816815108096
https://twitter.com/dan_abramov/status/1192579208423378946

Oh, there's so much going on here.
In my perspective, the tearing issue is relatively easy. We just take the approach either by use-subscription or reactive-react-redux. (Both have slight issues, but let's put aside.)
What's hard is the new pattern with Suspense and CM. Transitions and Render-as-You-Fetch pattern. This is not because of the core libraries redux and react-redux, but rather async middleware and best practices. In my blog post, I used "action hooks". My optimistic expectation is reactive-react-redux with no async middleware may work in CM. The question is if you call it a "React Redux" app, I mean what value do we get from Redux.

hum i think we are mixing many points together.
Suspense "loading states" capturing via throw promise it has nothing to do with react-redux.
instead startTransition that will stop low priority states commit will work perfectly with redux, as @eddyw demos shows.

I'm not sure if I'm on the same track, but what I'm suggesting is the pattern that Redux doesn't handle async functions including loading state. I'm not sure if that pattern is acceptable in the React Redux community, so that's my question. Yeah, this topic might be too broad.

I don't mean any rush, but while it's not an immediate priority, let's do some experiment.
I made a small repo for reproduction of "tearing" (as far as I understand).
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode
It would be nice if someone could review it as I might be biased.
Please file issues there about this tool or any related discussion, not to disturb this issue here.

hi, i have done some test with your demos, here are my 2 cents:
import React from 'react';
import { createStore } from 'redux';
import { Provider, useSelector, useDispatch } from 'react-redux';
import { unstable_runWithPriority, unstable_UserBlockingPriority } from 'scheduler';

import {
  syncBlock,
  useRegisterIncrementDispatcher,
  reducer,
  ids,
  useCheckTearing,
} from '../common';

const store = createStore(reducer);

const Counter = React.memo(() => {
  const count = useSelector(state => state.count);
  syncBlock();
  return
{count}
;
});

const Main = () => {
  const dispatch = useDispatch();
  const count = useSelector(state => state.count);
  useCheckTearing();
  useRegisterIncrementDispatcher(React.useCallback(() => {
    unstable_runWithPriority(unstable_UserBlockingPriority, () => {
      dispatch({ type: 'increment' });
    });
  }, [dispatch]));
  const [localCount, localIncrement] = React.useReducer(c => c + 1, 0);
  return (

      <button type="button" id="localIncrement" onClick={() => dispatch({ type: 'increment' })}>Increment remote from app</button>

Remote Count

      {ids.map(id => <Counter key={id} />)}

{count}

Local Count

      {localCount}
      <button type="button" id="localIncrement" onClick={localIncrement}>Increment local count</button>

  );
};

const App = () => (
  <Provider store={store}>

  </Provider>
);

export default App;

button onclick outside a ReactApp has lowpriority so dispatch-> "50 setStates" are "streamed" in more workInProgress Update and the "tearing" effect is Perfectly correct! CM "streams" low priority update like. the misundestandig about your demo is that an externa button is not "remote" low priorty work
Infact
a) wrapping around High priority userBlocking your externa button there is NO more tearing.
b) putting the button inside react app, react engine execute with userBlocking priority the "onClick" event and there is NO tearing.

your "reactive-react-redux" is not so "reactive" as it ALWAYS propagate reduxState via Context, that is EQUIVALENT tu dispatch always in userBlockingPriority (update 50 counter states at the same time) with the consequence that you will see jumps in the counter on screen when click fast.

so i think that tearing is not a bug, is the consequence of "streaming" updates from a "remote"
and react-redux is capable of that with every priority needed.

so if folks want IMMEDIATE update from everywhere then
function useImmediateDispatch() {
  const dispatch = useDispatch();
  return (...args) => {
    unstable_runWithPriority(unstable_UserBlockingPriority, () => {
      dispatch(...args);
    });
  };
}

@markerikson
import { unstable_discreteUpdates } from 'react-dom'

with unstable_discreteUpdates  instead of unstable_batchedUpdates,
in setBatch in CM there is no more tearing.
basically is the same as useImmediateDispatch

@salvoravida my demo just demonstrates what I was talking about. The "intentional tearing" caused by useTransition and what blocking updates look like. One issue I mentioned is "what to throw" which basically just means, how Redux can tell React to wait. From what I see this "waiting promise-like thing" should be a subscription itself?
Btw, the demo just works because state is actually in React state. If you replace these lines:

        {JSON.stringify(store.getState(), null, 2)}

with:

        {JSON.stringify(state, null, 2)}

This is outside of Suspense and .. the broken behavior? or what React would expect the state to look like in there.
@markerikson IMHO, from what I read ("Redux is broken") from Dan and what's on React docs, it kind of seems like they just want to say "Lift your state to where it matters instead of having a global store as React has been suggesting for years in their docs" or, let's just say it, ... multiple stores which is actually the reality (you can count all useState and useReducer as stores), so yeah ... ~and "use Relay" is silently mentioned everywhere~ 🙈
Anyways, I made a couple of codesandbox:
https://codesandbox.io/s/test-redux-in-concurrent-mode-with-react-redux-gj63q
This is with redux & react-redux. As Dan said in StackOverflow, wrapping with startTransition doesn't work
https://codesandbox.io/s/test-react-redux-in-concurrent-mode-without-redux-foxxo
This without Redux but with react-redux. It's a naive implementation of Redux using useReducer. This is the ""expected"" behavior. If you click on "start" and then type something in the input (which also dispatches an action), you'd see that the suspended state wasn't merged yet as long as the transition lasts (timeoutMs). Ignore the warning 😅, that's another thing to worry about.
I think we need a concurrent Redux 🙈

@de

Hi folks.
My idea is to change forceRender into useSelector hook, let instead set a state, and return that state.
This should transform redux state changes into react useState changes that should batched and eventually paused form react concurrent mode

in this pr https://github.com/reduxjs/react-redux/pull/1455
i fixed the erro of reading store state into render phase.
@dai-shi this fix tearing WITHOUT any priority wrapper even with with "your external buttton"
i will do e codenbox with your demo and my fix.

@eddyw throing promise to "comuncate" with Suspense si not releated with tearing, that i have fixed in upside PR.
i will investigate more on your demo as soon as possible, with new react-redux.

here is a temp build i you want to try in CM useSelector
"@salvoravida/react-redux": "^7.1.4",
Regards!

@eddyw
https://codesandbox.io/s/test-redux-in-concurrent-mode-with-react-redux-pytbh
HERE is your demo "Test Redux in Concurrent mode (with React-Redux)"
with
import { Provider, useSelector } from "@salvoravida/react-redux";
🎉 THAT IS 100% working with useTransition !!

Finally

The mental modal is -> store Changes -> subcriptions call -> enqueque storeState, NOT forceRender

Enjoy Redux & React-redux 100% CM compatible.
 Do not warry.

@eddyw

The "intentional tearing" caused by useTransition and what blocking updates look like.

I guess you already know it, but this "intentional tearing" is different from what I originally talked about, which is tearing in multiple components subscribing separately to a redux store. See this for more information.
We need better wording...

@salvoravida 👍 cool cool! ... but 🙈

enqueque storeState, NOT forceRender

wrap within React.memo, nothing will happen if within transition 🙈
https://codesandbox.io/s/test-redux-in-concurrent-mode-with-react-redux-salvoravidareact-redux-j2e17
A separate thing:
Warning: App triggered a user-blocking update that suspended.

The fix is to split the update into multiple parts: a user-blocking update to provide immediate feedback, and another update that triggers the bulk of the changes.

Refer to the documentation for useTransition to learn how to implement this pattern.

If not wrapping within React.memo, it works, but this warning still happens if typing on the input. Technically, none of the components within Suspense should re-render or update because they don't use that "slice" of state.. I think

I would suggest to split the discussion:

X works in concurrent mode but limits its UX benefits for the whole app

Isssue1: Existing React Redux apps that run in SyncMode should run in Concurrent Mode (createRoot)

X works in concurrent mode but limits its UX benefits for features written in X

Issue2: Existing React Redux apps to get benefit of concurrent rendering (priority)

X works in concurrent mode and lets its users take full advantage of its benefits

Issue3: What would Suspense-oriented React Redux apps look like and how a library should support new best practices

@eddyw

See #1351 (comment)
If component is wrapped within React.memo, it doesn't work 😛

here is the fix 😛😛😛 https://codesandbox.io/s/test-redux-in-concurrent-mode-with-react-redux-salvoravidareact-redux-9jo9z
but please note that is a bug of the current "experimental react" with "SimpleMemoComponent"
infact force memo Non simple it works.
react-dom-internal
function updateMemoComponent(current$$1, workInProgress, Component, nextProps, updateExpirationTime, renderExpirationTime) {
  if (current$$1 === null) {
    var type = Component.type;

    if (isSimpleFunctionComponent(type) && Component.compare === null && // SimpleMemoComponent codepath doesn't resolve outer props either.
    Component.defaultProps === undefined) {
      var resolvedType = type;

      {
        resolvedType = resolveFunctionForHotReloading(type);
      } // If this is a plain function component without default props,
      // and with only the default shallow comparison, we upgrade it
      // to a SimpleMemoComponent to allow fast path updates.

      workInProgress.tag = SimpleMemoComponent;
      workInProgress.type = resolvedType;

      {
        validateFunctionComponentInDev(workInProgress, type);
      }

      return updateSimpleMemoComponent(current$$1, workInProgress, resolvedType, nextProps, updateExpirationTime, renderExpirationTime);
    }

i will open a issue on React.
So this "issue" is not related to useSelector!

and here is: https://github.com/facebook/react/issues/17318

@salvoravida interesting ...
So, I just set defaultProps to continue playing 🙈
I implemented a very naive "Reducer suspense" which basically delays the reducer from setting its state until it's no longer in the transition:
https://codesandbox.io/s/test-redux-in-concurrent-mode-with-react-redux-salvoravidareact-redux-1xpwn
Seems to work well .. but I stumbled across a weird behavior. Typing in both inputs (one inside, another outside Suspense) dispatches the same action. This action is handled by two reducers, so the same text is set within posts.text and input.text (this was just to test that posts reducer state could be suspended). What is weird.., if you type in the second input (within Suspense), the first one doesn't get updated. In console, you can see that it is in fact updated in the Redux store. I don't know if this is an issue with the selector or not. I really can't make sense of it.

@eddyw i dont think that reducers are the place where throw anything!  reducers and redux must be pure.
i'm working on some different point to implement thrown from data coming from redux, but it will involve saga and loading states.
it has nothign to do with useSelector and react-redux.

@salvoravida yes, it's just a naive implementation
Btw, it is a bug in useSelector. I had this:
const text = useSelector(s => s.input.text);
However, this was suppose to be:
const text = useSelector(s => s.input);
No error or warning thrown/shown on console. :/

CM is SO GREAT!
CM "fast" dispatch

Sync mode dispatch

Fast low priority updates, will be batched, and ignored, with many less render!

@eddyw 🎉
PASS  __tests__/all_spec.js (12.341s)
  react-redux
    √ check1: updated properly (8053ms)
    √ check2: no tearing during update (1ms)
    √ check3: ability to interrupt render
    √ check4: proper update after interrupt (2108ms)

Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total

Has anyone looked into use-subscription hook? It was created at Facebook and is designed to safely manage subscriptions in concurrent mode.
I implemented hooks support in a redux-like solution for reason-react (reductive) using use-subscription. My first attempt was basically porting the current code for hooks in react-redux into reasonml, but then after long discussions we went with a slightly different approach with use-subscription.
Maybe it is something that can be used in react-redux? Appreciate any thoughts! 😄

@MargaretKrutikova : yeah, we'd based several aspects of our original implementation on that. Not sure how much we've deviated from at by now.

Hey all 👋,
I'm very excited about concurrent and suspense! Redux + React Redux are libraries we in production and it would definitely be a blocker for adoption if it didn't support concurrent mode etc.
I'm relatively new to this but I'm ready and excited to experiment and problem solve. I would like to suggest one starting topic of discussion to onboard myself and anyone else who is excited to experiment and try these features out:
What does supporting concurrent mode even mean?
This is very related to what @markerikson posted back in July quoting Dan.

We need to be clear that there are several “levels” of compatibility with new features of React. They’re not formalized anywhere yet but a rough sketch for a library or technique X could be:
X breaks in sync mode
X works in sync mode but breaks in concurrent mode
X works in concurrent mode but limits its DX and UX benefits for the whole app
X works in concurrent mode but limits its UX benefits for the whole app
X works in concurrent mode but limits its DX and UX benefits for features written in X
X works in concurrent mode but limits its UX benefits for features written in X
X works in concurrent mode and lets its users take full advantage of its benefits
This is not a strict progression and there’s a spectrum of tradeoffs. (For example, maybe there is some temporary visual inconsistencies such as different like counts, but no crashes are guaranteed.)
But we need to be more precise about where React Redux is, and where it aims to be.

I don't really need to answers for these in particular but I really just want to define what "supporting concurrent mode" means for Redux.
Here are my questions that would help me contribute:

How does Redux/React-Redux not support concurrent mode today? Is this just because of tearing?
Are there any definitions for concurrent-mode safe vs full concurrent mode support?
If so can we define what "concurrent-mode safe" and "full concurrent mode support" means for React-Redux?

Does CM safe mean no tearing issues? Does full CM support just mean making it work transitions (i.e. useTransition and useDeferredValue)? Does it mean more?

@ricokahler : yes, exactly!
The PR at #1455 looks like it's worth investigating further, but overall I would like to collect a much more detailed list of exactly what points of compat/incompat we are dealing with, figure out which of those are resolvable by lib changes if any, and formally document things.

This is from my experience and understanding from testing CM:

The tearing issue is described here by @markerikson -> https://stackoverflow.com/questions/54891675/what-is-tearing-in-the-context-of-the-react-redux
This is what the mentioned PR is trying to solve. That should make existing RR apps just work in CM (consistent rendering). Let's call it "concurrent-mode safe"

What doesn't work? I made this small demo: https://codesandbox.io/s/cm-simple-test-x5umg
This doesn't use Redux or React-Redux. Test this in the following ways:

First test: click "Start Suspense", then click several times "Increment with Transition", then "Stop Suspense"
You'll see that while you were incrementing, nothing was displayed on screen and this update happened on a "separate branch" of the state in memory until you stopped the transition.

Second test: click "Start Suspense", then click several times "Increment with Transition, then click "Increment without Transition", then "Stop Suspense"
You'll see something confusing lol
When you do "Increment with Transition" while in transition, this updates the forked state in memory, but "Increment without Transition" is updating both, the forked state and the current state.

The issue is, Redux is not able to create a "branch" of the state and update it in memory. Every action results in the whole store being updated, regardless of using transition or not. Now, React-Redux does keep the slice of the state you subscribed to in React state, so technically, it's possible to dispatch an action wrapped within a transition, since this is sync, it'd result in a state update within a transition and React will know to update this forked state. However, this behaves differently if you update the same slice of state with & without transition while a component is suspended.
This is the same demo but with Redux & React-Redux with @salvoravida changes:
https://codesandbox.io/s/cm-simple-test-tx34i
Do the "second test" described above and compare what happens.
So, it's not possible to "fix" this behavior because .. well, we can't. Redux just doesn't have a way to do branches (like git branches) of state since it isn't even aware of React.
Another "issue" is .. how to notify Suspense that we have the data ready? In the demo, you can see an example of how it can be done, but there isn't a guide of how to do it since this depends on your own implementation. React docs use wrapPromise which return .read() which either returns the value or throws. This should probably be implemented on user-side since there isn't a general way of doing it that will cover all user cases.
So, to be CM compatible, you need to know which actions you dispatch are wrapped within transition and make sure no other action modifies the slice of state that the transition depends on or it will cause a blocking-update. Maybe this could be baked within you action creators:
const fetchUserData = (isTransition) => ({ type: 'FETCH', isTransition })

And you could let the reducer, that handles that slice, know that the action dispatched was within a transition. Your reducer could then prevent any further action that is dispatched outside of a transition like this:
const reducer = (state, action) => {
   if (state.isTransition && !action.isTransition && action.type !== 'STOP_FETCH') {
      console.warn('Action dispatched while state is in transition')
      return state
   }
}

Point is, the lib can "help" but not solve all the issues. The tearing issue can be solve by the lib, but handling "Suspense" (what you "throw") and accidental blocking-update should probably be handled by user-side. The simple rule is, if your state was updated within "transition", then every other dispatched action should be within transition until .. quit the Suspense waiting state (if there is a better term for that)
However, that will just make it as close as possible to full CM support. It will work with Suspense and useTransition, but .., since there isn't a concept of branching states in Redux, any other part of the app that is subscribed to the state that is suppose to be "updated in memory but not displayed yet" could potentially still display the very last Redux state. You can see it here:
https://codesandbox.io/s/cm-simple-test-b1sqq

Click on "Start Suspense", click several times on "Increment with Transition" (don't click on "Stop Suspense")
Then start typing in the input box

You'll see that the input label got updated to display the latest value only when you typed and not when the store updated. I can see that here is where people could get really confused thinking that RR doesn't work but .. this is expected since the store has only one version. The reason why it didn't update when store changed is because the selector value was got within a transition, so the Input component bails out of rendering, however, typing on the input causes the component to re-render which shows the latest selected value. With React state only, this value wouldn't update and typing on the input wouldn't display the "other branch"
For this last issue, could the lib help? I really don't know. Maybe if RR were to provide its own useTransition hook, then RR would be aware of which dispatched actions should cause a "merged store"? or maybe this just shouldn't be the job of RR to solve, maybe it could be solved with a special store enhancer or middleware for Redux? Or should we just write it as "best practices" not to subscribe to slice of state that will be used within "Suspense"?

@eddyw : yeah, the issue you're describing with "lack of state branching" is something Dan was specifically pinpointing.
I've had very vague ideas of some kind of store enhancer that could juggle in-flight actions, wait for React to actually be ready to commit them, and then finally apply them to the Redux store, but tbh it seems like a horribly complex idea that probably wouldn't work out well.
If you look back in the very early "async React" issues from last year (like #890 ), Dan and Andrew were suggesting hypothetically creating an API-compatible "Redux store" on top of React state, to allow React to control the queueing of state updates. Unfortunately, I think that's also a non-starter, because there's a lot of need to interact with the store outside the React component tree, and I think that the perf behavior would be significantly worse overall based on what I've seen from v6 and v7.
But sure, I'm open to ideas and experiments to see how things might actually work out.  Anything that gives us more specific data on possibilities and limitations is good.

Isssue1: Existing React Redux apps that run in SyncMode should run in Concurrent Mode (createRoot)

How does Redux/React-Redux not support concurrent mode today? Is this just because of tearing?

This question is very important. There are two cases:
a) existing apps break without the use of useTransition
b) existing apps break with the use of useTransition (direct use like @eddyw does, or using somewhere in code not related to react-redux)
By using useLayoutEffect, we can de-opt to sync mode even if we are in concurrent mode, so we could do that when we find inconsistency from the external store.
Issue2: Existing React Redux apps to get benefit of concurrent rendering (priority)

Has anyone looked into use-subscription hook? It was created at Facebook and is designed to safely manage subscriptions in concurrent mode.

I'm hoping if we use the same technique in use-subscription, we might be able to get benefit of priority. But because redux store is external anyway, I'm not sure how much benefit we could get.
Issue3: What would Suspense-oriented React Redux apps look like and how a library should support new best practices
So, one in question is how we could live with <Suspense> and useTransition.

"lack of state branching"

Based on @eddyw 's codesandbox:

reactive-react-redux version
https://codesandbox.io/s/cm-simple-test-9zd1s
It works a bit more consistent but not as expected because lack of branching
react-tracked version
https://codesandbox.io/s/cm-simple-test-1hd5l
It works as expected with branching but it's not redux anymore

This is from my experience and understanding from testing CM:

The tearing issue is described here by @markerikson -> https://stackoverflow.com/questions/54891675/what-is-tearing-in-the-context-of-the-react-redux
This is what the mentioned PR is trying to solve. That should make existing RR apps just work in CM (consistent rendering). Let's call it "concurrent-mode safe"
What doesn't work? I made this small demo: https://codesandbox.io/s/cm-simple-test-x5umg
This doesn't use Redux or React-Redux. Test this in the following ways:

First test: click "Start Suspense", then click several times "Increment with Transition", then "Stop Suspense"
You'll see that while you were incrementing, nothing was displayed on screen and this update happened on a "separate branch" of the state in memory until you stopped the transition.
Second test: click "Start Suspense", then click several times "Increment with Transition", then click "Increment without Transition" a couple of times, then click on "Stop Suspense"
You'll see something confusing lol
When you do "Increment with Transition" while in transition, this updates the forked state in memory, but "Increment without Transition" is updating both, the forked state and the current state. When you stop the transition, both merged

The issue is, Redux is not able to create a "branch" of the state and update it in memory. Every action results in the whole store being updated, regardless of using transition or not. Now, React-Redux does keep the slice of the state you subscribed to in React state, so technically, it's possible to dispatch an action wrapped within a transition, since this is sync, it'd result in a state update within a transition and React will know to update this forked state. However, this behaves differently if you update the same slice of state with & without transition while a component is suspended.
This is the same demo but with Redux & React-Redux with @salvoravida changes:
https://codesandbox.io/s/cm-simple-test-tx34i
Do the "second test" described above and compare what happens.
So, it's not possible to "fix" this behavior because .. well, we can't. Redux just doesn't have a way to do branches (like git branches) of state since it isn't even aware of React.

i'm not SO SURE that React "branch merge" is a such desiderable thing. it works with counter and setCounter( prevCounter => prevCounter +1), but what about merging states that "time" depending on prev States? will the merge be consistent? i DO NOT THINK  SO.
Probably React should NOT allow to equeue states inside startTransition, and outSide contemporalrly!
Remember that when you MERGE you can have Conflict!

@salvoravida I made this sandbox: https://codesandbox.io/s/cm-simple-test-bj47d
It's mentioned that React batches updates in the suspended component (I don't recall where is that 🙈 ). However, "batching" doesn't mean .. "batching" lol
To understand better, please try it in sandbox and check console. What happens is something like this:
initialState => { counter: 0 }
// with transition
action1 = dispatch(...) => merge(initialState, action1) <<< counter: 1
action2 = dispatch(...) => merge(initialState, action1, action2) <<< counter: 2
action3 = dispatch(...) => merge(initialState, action1, action2, action3) <<< counter: 3
// without transition
action 4 = dispatch(...) => set initialState => { counter: 1 } <<< this is displayed
=> merge(
  initialState, <<< new is { counter: 1 }
  action1, <<< counter: 2
  action2, <<< counter: 3
  action3, <<< counter: 4 (this is what you'll see once you stop Suspense)
)

This is how it's batched, it's like every previous action is re-dispatched on top of the initial value. If value changes outside of transition, that becomes the new initial value and every other update is applied on top of it. This is my understanding of how it works based on testing.
This is not actually documented, it's just said to be ""batched"". However, testing it, it works like every new set value or dispatched action within a transition gets applied on top of previous dispatched actions. Technically, it replays all previous actions and adds the latest dispatched on top. So, like rebase.. literally haha
This means, it is actually possible to do this with Redux. The following would be the equivalent of the above useReducer. It'd mean, create a "temporary store" using the same store reducer/s with the initial value as current store value. Every dispatched action within a transition would go to "temporary store" (speudo-code):
temporaryStore = createStore(store.reducer, store.getState()) // state = { counter: 1 }
... // within transition
dispatch({ type: 'INCREMENT' }) => // action 1
    temporaryStore = createStore(reducer, store.getState())
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 2 }
dispatch({ type: 'INCREMENT' }) => // action 2
    temporaryStore = createStore(reducer, store.getState())
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 2 }
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 3 }
dispatch({ type: 'INCREMENT' }) => // action 3
    temporaryStore = createStore(reducer, store.getState())
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 2 }
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 3 }
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 4 }
... // outside transition
dispatch({ type: 'INCREMENT' })
    store.dispatch({ type: 'INCREMENT' }) => { counter: 2 }
    temporaryStore = createStore(reducer, store.getState())
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 3 }
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 4 }
    temporaryStore.dispatch({ type: 'INCREMENT' }) => { counter: 5 }
... on Suspense Stop, applies batch of updates:
   store.dispatch({ type: 'INCREMENT' }) => { counter: 3 }
   store.dispatch({ type: 'INCREMENT' }) => { counter: 4 }
   store.dispatch({ type: 'INCREMENT' }) => { counter: 5 } <== it's in sync with temporaryStore

This is why it's said that it's "batched" and it works "like rebase" because every action is applied on top of the master branch but on a separate branch.
Where this wouldn't work?
The fundamental difference between Redux and React useReducer is that, React's dispatch is pure while in Redux, this can be messed with if you apply middleware on top of it such as .. sagas, so you can't really dispatch the same actions in both stores without side-effects. For instance, if dispatch({ type: 'FETCH' }) starts a http request, then dispatch is not pure and you'll end up having the same request in a temporary store.

@eddyw i come on the same conclusion, react on start action fork the states one with ALL setStates and one without transaction states (the temporary UI) on Stop transaction it will not MERGE but SWAP the branches....

@salvoravida it doesn't SWAP the branches, it replays all the actions in the "master" branch. In the above demo, you can see that once you click on "Stop Suspense", it will log once again every single action that was dispatched while in transition, so it literally is like REBASE.
It's more or less like doing this:
const previousActions = []
const createTmpStore = () => createStore(reducer, store.getState(), c => (...args) => {
  const str = c(...args)
  const orgDispatch = str.dispatch
  const dispatch = action => {
     previousActions.push(action)
     return orgDispatch(action)
  }
  previousActions.forEach(action => orgDispatch(action)) // replay previous actions
  return { ...str, dispatch }
})

// start transition
let tmpStore = createTmpStore()
...
dispatch(...) => tmpStore = createTmpStore().dispatch(...)
dispatch(...) => tmpStore = createTmpStore().dispatch(...)
dispatch(...) => tmpStore = createTmpStore().dispatch(...)
previousActions.length => 3 [{ ... }, { ... }, { ... }]

// stop transition
previousActions.forEach(act => store.dispatch(act))
previousActions.length = 0
// <<<<< note, it doesn't swap, it "rebases" all previous actions on top of current store

Hm, so, I did this:
https://codesandbox.io/s/cm-redux-e6m2i
It's a store enhancer for Redux. It's ugly but works. It creates the store but it doesn't allow dispatching actions outside of a React app. When used in a React app, useReducer handles internally the Redux reducer, so React becomes owner of the state.
This is just an idea, in the above, the enhancer over-writes getState, subscribe, and dispatch. So basically, the whole thing that makes Redux .. Redux to make React owner of the state. It will make no sense at first to use Redux at all .. but, the idea is that, taking out the enhancer, it should still work without React, in which case, using Redux still makes sense even if it's over-writing the whole logic behind it.
Maybe making an enhancer that returns a compatible Redux API actually makes sense. This just to make React owner of the state, so we don't need to worry about "fixing Redux" since React already has useReducer which does basically the same as createStore. Middleware is a complete different story to worry about.

i cannot agree at all to make react own redux state. redux state can be used outside of react, for others 1000 reasons. like microfronteds communication, orchestrator, iframe channel etc..
if we use Redux, we do not want to "depends" on react.
maybe we shoud create a redux with branches.

Issue 3: What would Suspense-oriented React Redux apps look like and how a library should support new best practices
@eddyw Wow, nice try. And it raises a question: What is Redux?
My conclusion is state branching (which no longer is a single source) is not possible with the current Redux lib. So, I think there are two options: 1) keep backward compatibility and give up state branching (still apps work in CM and Suspense. useTransition to some extent). 2) break backward compatibility for state branching and create a new React Redux lib that will support say 80% of existing apps.
Well, it might be too early for the conclusion. Let's keep discussing...

i cannot agree at all to make react own redux state. redux state can be used outside of react, for others 1000 reasons. like microfronteds communication, orchestrator, iframe channel etc..
if we use Redux, we do not want to "depends" on react.
maybe we shoud create a redux with branches.

Just throwing random ideas. The above would work dispatching actions outside of React, only once React has initialized. Although, I can see many issues with my implementation (even if done right). For example, if you have two react apps, which is completely valid, the state here wouldn't be able to be shared since only one root instance will own the state.

Issue 3: What would Suspense-oriented React Redux apps look like and how a library should support new best practices
@eddyw Wow, nice try. And it raises a question: What is Redux?
My conclusion is state branching (which no longer is a single source) is not possible with the current Redux lib. So, I think there are two options: 1) keep backward compatibility and give up state branching (still apps work in CM and Suspense. useTransition to some extent). 2) break backward compatibility for state branching and create a new React Redux lib that will support say 80% of existing apps.
Well, it might be too early for the conclusion. Let's keep discussing...

I honestly don't see how it could break backwards compatibility. This "branching" only happens when you set state within transition. Current apps just don't use transition.
Now, if you move your app to CM mode, then start using transition and suspense with React Redux, that's migration and refactoring.
If you mean that current apps using RR, should work the same way in CM as they worked before even when using transition, then that's a wrong assumption. In CM, you can't avoid branching of state if you're using transition, I mean .. just don't randomly wrap everything is startTransition. RR uses React state internally to keep selectors, for instance, so if a dispatched action is within a transition, there will always be branching in the selectors that update because of that dispatched action. The issue is, the components that will see branching outside of Suspense will just bail out of re-rendering, if the component is force-rendered, then it'll display the latest value.
So, if we just fix tearing and keep everything else as is, this would be the "best practice" rule:
– If you dispatch an action within a transition, make sure the slice of state that is changed only affects the components within Suspense. If you have a component subscribed to the same slice of state outside of Suspense, then expect it to display inconsistent data.
This is what "support 80% of CM features with RR" would mean: useTransition and Suspense works as long as you follow that rule.
However, in practice this could be difficult to follow in big React apps.
What I got so far is that RR could possibly do little to have full CM support. The last "20% missing support" is branching on Redux itself which probably shouldn't be RR responsibility? Since we don't have an "Async Redux", it's difficult to know if RR could help any further.
Idk, I'll just keep on experimenting, it's a nice learning experience lol

https://twitter.com/dan_abramov/status/1193963224540090380
i think we cant yet understanding how CM branches merge/swap we have to wait for stable version

@eddyw Thanks for the summary. Totally agreed.
Issue 1: Existing React Redux apps that run in SyncMode should run in Concurrent Mode (createRoot)
Issue 2: Existing React Redux apps to get benefit of concurrent rendering (priority)
If we don't use Suspense and useTransition, which is my Issue 1 & 2, there's no branching. There's little left to do hopefully, unless we find some other issues. (I think there are.)
Issue 3: What would Suspense-oriented React Redux apps look like and how a library should support new best practices
If we useTransition, that requires some rules or limited behaviors. That's probably fine. What about middleware? You said it's a different story, but can we set a small set of rules to useTransition properly with middleware? I mean, it's OK to set rules for RR, but we would need to set rules for Redux too for branching. (So, I should have said backward compatibility with useTransition for the entire redux eco system, which might be a wrong assumption.)
But, that's still a tiny issue. Honestly, if I were to use Suspense and useTransition, I wouldn't put loading state in redux store. I wouldn't want to write throw promise in my app code. Some middleware may not work. It looks to me a dead end.

https://github.com/facebook/react/pulls
🎉 habemus papam ! 🎉

Brian Vaughn just posted the RFC for the useMutableSource hook:
https://github.com/reactjs/rfcs/pull/147

While it's quiet here, here's my implementation of react-redux basic hooks with the currently proposed useMutableSource.
 const StoreContext = createContext();
 const subscribe = (store, callback) => store.subscribe(callback);
 const Provider = ({ store, children }) => {
   const contextValue = useMemo(() => ({
     source: createMutableSource(store, () => store.getState()),
     dispatch: store.dispatch,
   }), [store]);
   return (
     <StoreContext.Provider value={contextValue}>
       {children}
     </StoreContext.Provider>
   );
 };
 const useDispatch = () => useContext(StoreContext).dispatch;
 const useSelector = (selector) => {
   const selectorRef = useRef(selector);
   useLayoutEffect(() => {
     selectorRef.current = selector;
   });
   const getSnapshot = useCallback((store) => selectorRef.current(store.getState()), []);
   const { source } = useContext(StoreContext);
   return useMutableSource(source, getSnapshot, subscribe);
 };

I'm experimenting it with my tool.

@dai-shi : yeah, I think my immediate questions would be:

does this improve the pass/fail results on the CM test?
Does this affect the perf benchmarks in some way?
Does this relate to Suspense handling at all?

does this improve the pass/fail results on the CM test?

According to my observation, it improves but not completely like described in the gist.
To me, it still seems to behave like useSubscription. Not sure where the root cause is. Some of my implementation or assumption could be wrong.

Does this affect the perf benchmarks in some way?

I've done a preliminary test with use-context-selector: https://github.com/dai-shi/use-context-selector/pull/12#issuecomment-589877551
So far, so good. This is just a simple benchmark with just one or two useSelector. We would eventually need to test with react-redux-benchmarks.

Does this relate to Suspense handling at all?

Depends on what you mean by Suspense handling. State branching with useTransition would never be possible with an external store like Redux. Other than that, it should already be working as is.
So, the answer is no, I don't think this relates to it.

State branching with useTransition would never be possible with an external store like Redux.

I was wrong. I didn't try everything. Here's a version to support state branching. It's more like react-redux v6.
const StoreContext = createContext();
const subscribe = ({ subscribersRef }, callback) => {
  const subscribers = subscribersRef.current;
  subscribers.push(callback);
  return () => {
    const index = subscribers.indexOf(callback);
    subscribers.splice(index, 1);
  };
};
const Provider = ({ store, children }) => {
  const [storeState, setStoreState] = useState(store.getState());
  useEffect(() => {
    const callback = () => {
      setStoreState(store.getState());
    };
    const unsubscribe = store.subscribe(callback);
    callback();
    return unsubscribe;
  }, [store]);
  const storeStateRef = useRef(storeState);
  const subscribersRef = useRef([]);
  useEffect(() => {
    batchedUpdates(() => {
      storeStateRef.current = storeState;
      subscribersRef.current.forEach((callback) => callback());
    });
  });
  const contextValue = useMemo(() => ({
    source: createMutableSource({ storeStateRef, subscribersRef }, () => storeStateRef.current),
    dispatch: store.dispatch,
  }), [store]);
  return (
    <StoreContext.Provider value={contextValue}>
      {children}
    </StoreContext.Provider>
  );
};
const useDispatch = () => useContext(StoreContext).dispatch;
const useSelector = (selector) => {
  const selectorRef = useRef(selector);
  useLayoutEffect(() => {
    selectorRef.current = selector;
  });
  const { source } = useContext(StoreContext);
  const getSnapshot = useCallback(
    ({ storeStateRef }) => selectorRef.current(storeStateRef.current),
    [],
  );
  return useMutableSource(source, getSnapshot, subscribe);
};

Questions and notes:

Is it abusing useMutableSource?
I still see tearing with the current implementation of useMutableSource. Might be a bug. Or, I misunderstand something.
batchedUpdates is probably unnecessary.
This is potentially an answer to what Dan said something like Redux is not compatible with CM.

useMutableSourceHook just got merged into master:
https://github.com/facebook/react/pull/18000#issuecomment-597827200

I don't have time to play with this myself atm, but I'd be very interested to see a PR that tries to convert useSelector to be based on useMutableSource.  I'm also curious if connect can be made to work with it as well.

https://github.com/reactjs/rfcs/pull/147#issuecomment-597953813
FWIW, I tried the stale props spec in https://github.com/reduxjs/react-redux/pull/1505 with use-context-selector v2 with useMutableSource, and it failed unfortunately.

I've been making some progress with useMutableSource, but I need to figure out why act() isn't waiting for dispatches in tests and deal with errors in an example app.

@nickmccurdy Just a guess, but please try rtl.act() instead of act().
That worked for me: https://github.com/reduxjs/react-redux/pull/1536/files#diff-8a4f74cb696e74165240c9af9cb0ce45R188

So, I re-implemented my reactive-react-redux with useMutableSource.
https://www.npmjs.com/package/reactive-react-redux/v/5.0.0-alpha.1
https://github.com/dai-shi/reactive-react-redux/pull/48
This version of the API is slightly different from react-redux v7. It doesn't depend on Context. Developers will create a context at their requirement. (BTW, I heard MobX takes the same approach.)
Of course, it can be used without Context if one wants.

In terms of implementation for react-redux v7, looking at my snippet again, I think this one still suffers from the race condition issue #1536.

Nice. Does this still support multiple store contexts like React Redux?

Yes, I mean r-r-r doesn't care how developers use contexts with it.
Here's the example how to use a context with the API in r-r-r.
https://github.com/dai-shi/reactive-react-redux/blob/a57a033f676130283a414990d8cc4d8486a608fb/examples/12_async/src/context.ts

A simplistic implementation of connect using useMutableSource might look something like this:
const requiresOwnProps = mapStateOrMapDispatch => {
  return (
    typeof mapStateOrMapDispatch === 'function' &&
    mapStateOrMapDispatch.length !== 1
  )
}

const applyMapStateToProps = (mapStateToProps, state, props) => {
  if (typeof mapStateToProps === 'function') {
    return requiresOwnProps(mapStateToProps)
      ? mapStateToProps(state, props)
      : mapStateToProps(state)
  }
  return EMPTY_OBJECT
}

const applyMapDispatchToProps = (mapDispatchToProps, dispatch, props) => {
  if (typeof mapDispatchToProps === 'function') {
    return requiresOwnProps(mapDispatchToProps)
      ? mapDispatchToProps(dispatch, props)
      : mapDispatchToProps(dispatch)
  }
  if (mapDispatchToProps && typeof mapDispatchToProps === 'object') {
    return bindActionCreators(mapDispatchToProps, dispatch)
  }
  return { dispatch }
}

const defaultMergeProps = (stateProps, dispatchProps, ownProps) => {
  return { ...ownProps, ...stateProps, ...dispatchProps }
}

const useStableObject = obj => {
  const objRef = useRef(obj)
  useLayoutEffect(() => {
    objRef.current = obj
  }, [obj])
  return shallowEqual(obj, objRef.current) ? objRef.current : obj
}

const useStateProps = (mapStateToProps, ownProps) => {
  const { source } = useContext(ReactReduxContext)
  const propsForMapState = requiresOwnProps(mapStateToProps) ? ownProps : null

  const getSnapshot = useCallback(
    store =>
      applyMapStateToProps(mapStateToProps, store.getState(), propsForMapState),
    [mapStateToProps, propsForMapState]
  )
  const stateProps = useMutableSource(source, getSnapshot, subscribe)
  return useStableObject(stateProps)
}

const useDispatchProps = (mapDispatchToProps, ownProps) => {
  const { dispatch } = useContext(ReactReduxContext)
  const propsForMapDispatch = requiresOwnProps(mapDispatchToProps)
    ? ownProps
    : null
  return useMemo(
    () =>
      applyMapDispatchToProps(
        mapDispatchToProps,
        dispatch,
        propsForMapDispatch
      ),
    [mapDispatchToProps, dispatch, propsForMapDispatch]
  )
}

const useMergeProps = (mergeProps, stateProps, dispatchProps, ownProps) => {
  return useMemo(() => mergeProps(stateProps, dispatchProps, ownProps), [
    mergeProps,
    stateProps,
    dispatchProps,
    ownProps
  ])
}

const connect = (
  mapStateToProps = null,
  mapDispatchToProps = null,
  mergeProps = defaultMergeProps
) => WrappedComponent => {
  const MemoizedWrappedComponent = React.memo(WrappedComponent)

  if (mapStateToProps) {
    return React.memo(props => {
      const ownProps = useStableObject(props)
      const stateProps = useStateProps(mapStateToProps, ownProps)
      const dispatchProps = useDispatchProps(mapDispatchToProps, ownProps)
      const mergedProps = useMergeProps(
        mergeProps,
        stateProps,
        dispatchProps,
        ownProps
      )
      return <MemoizedWrappedComponent {...mergedProps} />
    })
  } else {
    return React.memo(props => {
      const ownProps = useStableObject(props)
      const dispatchProps = useDispatchProps(mapDispatchToProps, ownProps)
      const mergedProps = useMergeProps(
        mergeProps,
        EMPTY_OBJECT,
        dispatchProps,
        ownProps
      )
      return <MemoizedWrappedComponent {...mergedProps} />
    })
  }
}

The React team has announced plans for React 18, per https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html , and created a "React 18 Working Group" discussion forum at https://github.com/reactwg/react-18/discussions .
I just filed an issue asking for people to try out React-Redux v7 and the React 18 alphas together, and let us know what sorts of issues pop up. We'd love to have folks help out with this!

Sharing my experience related with uMS in React 18 alpha, which is unstable_, one thing to note is "stable selectors".
I noticed while experimenting "tearing" with redux with uMS, wrapping a selector with useCallback is necessary.
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering/blob/d8dee99d068b980b28aacddc476cb0643ccb63d9/src/redux-use-mutable-source/index.js#L38
changing this to
  const getSnapshot = (s) => selectCount(s.getState());

causes infinite loop like behavior.
In reactive-react-redux, I added a note "selector has to be stable. Either define it outside render or use useCallback if selector uses props."
In zustand, I added a note "It is generally recommended to memoize selectors with useCallback.", but this is going to be a requirement with breaking change.

I'm going to close this because I think it's resolved by the work done in #1808 .  I'd still like to see more folks try out React-Redux v8 and give us feedback in #1732 .


Any idea when Azure support comes back ?

Hi everybody,
do you have any idea, when Azure support comes back to the installer for OKD4 ? It seems to being stripped out for the preview for some reason.
Many friendly greetings,
Josef

Related to https://github.com/openshift/okd/issues/13 provider

Closing in favor of #13


NRF_HAL library URL fix

Some time ago I changed NRF_HAL repository name to match library name. This PR contains fixed URL.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @per1234.
Could you tell me what this repository is intended for? Are you going to change a method of adding new contributors repositories into Library Manager by replacing legacy method (submitting PRs to Arduino)?

Are you going to change a method of adding new contributors repositories into Library Manager by replacing legacy method

That's exactly it.
There will be an official announcement about it soon. Until then, you can see details in the readme:
https://github.com/arduino/library-registry#readme

Thanks for the clarification. That's very good idea - the process will became more automatic w/o additional human intervention as currently.


How to limit the upload target's mime type or the bytes size?

It is currently not possible to validate ActiveStorage attachments, however this is introduced in Rails 6. Once you're using a version of Rails that supports this, validations (such as on mime type) should work outside of the box.


bug: build.rs STILL not quite right

Describe the bug
build.rs does not work in all situations.
To Reproduce
Steps to reproduce the behavior:

Change src/lib.rs of a package
It doesn't rebuild

Expected behavior
It rebuilds the package
Additional context
The src/ rebuild prints are not being printed; the Cargo ones are.

it is perfect now
https://github.com/kinode-dao/kinode/pull/446/commits/e3366efd4f80a4bbc3454d41c873af669794335d


Update url for /store/logs/prod/recent

I just noticed the https url I've been using since day 0 (eoscmshttp...) is no longer working, e.g.:
https://eoscmshttp.cern.ch/eos/cms/store/logs/prod/recent/TESTBED/amaltaro_MonteCarloFromGEN_HG1808_Validation_180725_154304_9472/MonteCarloFromGEN/vocms0192.cern.ch-11822-0-log.tar.gz
while asking Daniel (VoC) to create a ticket for CERN IT, he has found this old snow ticket
https://cern.service-now.com/service-portal/view-request.do?n=RQF0957020
which says the endpoint is actually "eoscmsweb.cern.ch", since March...

Ok, the situation isn't that bad since it doesn't touch reqmgr, it's all on the agent side.

Daniel asked them to re-enable that alias. So both url will work until the VoC ask CERN IT to disable eoscmshttp one. Anyways, the sooner we patch the agents the better.

Hi Alan,
Hold on, let's coordinate first - there's another SNOW ticket that just closed to remove the alias:
https://cern.service-now.com/service-portal/view-incident.do?n=INC1749765
We had Herve remove the alias because the X509 authentication was never setup correctly for eoscmshttp (hm - did we stageout via Xrootd?  It certainly shouldn't have worked for HTTP).
Brian

Yes, stage out is done via xrdcp.

Sigh.  Can you comment on that SNOW ticket then?
(But yes, let's change over agents ASAP...)


Fix bug in customiseNSURLSessionConfiguration

What
By default, the NSURLSessionConfiguration gets overwritten with nil in CDTURLSession#initWithCallbackThread:requestInterceptors:sessionConfigDelegate: here.
Why
The overwriting of the NSURLSessionConfiguration should be prohibited as if it is overwritten with nil or a NSURLSessionConfiguration that is not configured for background transfers, all replications will fail.
The API should only allow the customisation of the session configuration object that is created in CDTURLSession#initWithCallbackThread:requestInterceptors:sessionConfigDelegate:, which is configured to perform transfers in the background.
How
Change the signature of customiseNSURLSessionConfiguration: in the CDTNSURLSessionConfigurationDelegate protocol so it returns void rather than an NSURLSessionConfiguration.  This allows customisation of the NSURLSessionConfiguration provided in the argument to customiseNSURLSessionConfiguration:, without allowing the replacement of the NSURLSessionConfiguration.
Change the call to customiseNSURLSessionConfiguration: in CDTURLSession so that the configuration is just passed to customiseNSURLSessionConfiguration: and the existing configuration is not overwritten.
Testing
The existing tests have been updated to use the modified customiseNSURLSessionConfiguration:.
The testFiltersWithChangesFeed test in CDTReplicationTests exploited the ability to replace the NSURLSessionConfiguration in order to allow OHHTTPStubs to be used to mock the responses from a server.  However, OHHTTPStubs cannot be used with background sessions, so the use of OHHTTPStubs in this test has been replaced with a simple HTTP server running on localhost that responds to any request it is sent with an HTTP 404 Not Found message.
Reviewers
reviewer: @alfinkel
reviewer: @rhyshort

+1

I'm guessing the two Jenkins build failures are a non-issue?

@alfinkel Sadly yes, the Jenkins build fail because of encryption tests, and I don't know what the magic incantation is to get them working again

+1


feat: update Layout Premitive Components

update Layout Premitive Components

this is my mistake.
I tried to make PR in my forked repository


SW-3952 Reduce default confidence interval to 80%

Based on feedback from our carbon consultant, we only need an 80% confidence level
on observations, not 90%. Change the default Student's t value to 1.282, which
corresponds with an 80% confidence level, and reduce the default number of
permanent clusters and temporary plots based on the new value.
This only changes the default for new planting sites; existing ones can be edited
in the admin UI if needed.

Current dependencies on/for this PR:

main

PR #1313   👈

This comment was auto-generated by Graphite.


Should policy request be created when active policy already exists for user+resource?

Closing issue since AAA server does not manage policies anymore


Seg fault in TGRSIRootIO

I got a seg fault in TGRSIRootIO in TGRSIRootIO::FinalizeFragmentTree() on line 121:
chan->SetNameTitle(Form("TChannels[%i]",TChannel::GetNumberOfChannels()),
Form("%i TChannels.",TChannel::GetNumberOfChannels()));
chan is 0.  The stack trace is:
TGRSIRootIO::FinalizeFragmentTree() at TGRSIRootIO.cxx:121 0x100085349
TGRSIRootIO::CloseRootOutFile() at TGRSIRootIO.cxx:178 0x10008559b
EndRun() at TGRSILoop.cxx:71 0x10003ca07
TGRSILoop::ProcessMidasFile() at TGRSILoop.cxx:216 0x10003ca07
The command I ran is:
/Users/gdemand/DESCANT/rawdata/offset_run02151_000.mid.bz2 -ql --suppress_errors

Did this start here: 179ae338775758f4342aa6346794aefc0ff0e18d ?

I haven't checked where it started yet (none of the changed files seemed relevant).
I have investigated further, and it seems that using the -O2 option causes TGRSILoop:SetFileOdb() to fail to read the experiment name from the data file, and hence not initialize any TChannels.  I'm not sure why it started doing this.

Maybe a naive question....Where are you using that option?

I have the same problem, but only on my apple. Linux seems to be working. Is this what you are seeing?

Yup, that's what I'm seeing.  For now, I can probably disable optimizations
on my apple, but I think that this is indicative of a problem with the code.
On Mon, May 4, 2015 at 2:12 PM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

I have the same problem, but only on my apple. Linux seems to be working.
Is this what you are seeing?
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/299#issuecomment-98801679
.

The XML output is completely different on the two platforms if I print out all of the node names. This might be a problem with the way ROOT does the XML on the two different OS.

Actually this is our class causing the problem. I'll see if I can find something.

Yeah, I'd say I have to agree with you. Something about the XML parsing code breaks when we try to optimize with clang above the O1 level. I'm trying to find the flags that get added with O2 to try to help debug, but I'm having a tough time.

I did some digging and it turns out that there is a bug in our versions of clang that don't like infinite while loops and optimizes them away. I'll see if I can workaround this.

Fixed on darwin.

Excellent.  It works for me as well.  However on a possibly related note, if I compile using O1 it seg faults on TXMLNode::HasChildren() at TXMLNode.cxx
with stack trace:
TXMLNode::HasChildren() at TXMLNode.cxx:168 0x104b67958
TGRSILoop::SetFileOdb() at TGRSILoop.cxx:260 0x10004ca9b
TGRSILoop::ProcessMidasFile() at TGRSILoop.cxx:197 0x10004c3f6

Hmm... I don't get the same thing. Did you run make clean?

Sorry, I do get the same thing, I ran it on the wrong computer.

Fixed. See #307


API

I am from China,I apply for an API in Bithumb, However,when I visit the private  method ,it tells me
"Invalid secretkey",I am sure it is right,besides,I have fixed the  API with ip in China,I use the demo
python3 program provided by Bithumb..
can you give me some advice?

You should make account_info.py at root directory and include variables like the form below:
api_key = "YOUR API KEY"
api_secret = "YOUR API SECRET KEY"

Also, this api_key and api_secret should be handled by the method xcoinApiCall which is included in  xcoin_api_client.py


🤺 Updates for v1.3.3

[x] #28
[ ] #34
[ ] #35
[x] #30
[x] #32

Issues that will be be a part of the website in the next iteration:

[ ] #29
[ ] #31


What are the Drupal cache recommendations?

What kind of caching should we aim to have set on Drupal? Does it make sense to have page cache? Does it make sense to have Dynamic cache?
What about this on top of upstream caches? I am thinking of disabling everything to start with, just wondering what would be the recommended approach.
Related to #246

Depends on how you're using the Drupal backend. The Drupal cache config does not affect the Next.js site (since JSON:API takes care of revalidating entity caches).
I use the Drupal backend mostly for editors (so authenticated sessions) but I generally always keep the page and dynamic caches on.

Chiming in: I've been testing with a stack using memcache (hold Drupal's render, dynamic page cache, etc. But no page_cache)) and Varnish (alongside Purge module) and everything has been OK so far. If your Next.js app is configured with authentication using Authorization it'll end up bypassing Varnish anyway and only leveraging dynamic page cache.


API Set up

Make the API available and ship it to the frontend:

Should be in a JSON format.
Should be able to display it in the frontend.