React-native: Async storage doesn't work when debugging in chrome using genymotion emulator

[austinksmith]

Using a macbook pro running 10.11.4 El Capitan

Using AsyncStorage api with android geny motion emulator, when debugging in chrome AsyncStorage does not operate

   componentWillMount: function() {
       var token;
       AsyncStorage.getItem('token').then((data) => {
         if(data) {
           token = data;
           return token;
      } else {
        this.setState({
          noAuth: true
        });
      }
    }).then((token) => {
      setTimeout (() => {
        this.setState({
          token: token,
          loading: false,
          noAuth: true
        });
        this.props.navigator.push({
          id: 'HomeView',
          passProps: {'state': this.state},
          sceneConfig: Navigator.SceneConfigs.FadeAndroid
        });
      }, 300);
    }).

This seems to run, but my timeout/navigate to never hits the homepage if i'm in debug mode, obviously this presents a few problems because then i can't debug why things aren't working lol. Any guidance would be much appreciated. Thanks.

[DanielMSchmidt]

@facebook-github-bot stack-overflow

[ghost]

Hey @austinksmith and thanks for posting this! @DanielMSchmidt tells me this issue looks like a question that would be best asked on StackOverflow. StackOverflow is amazing for Q&A: it has a reputation system, voting, the ability to mark a question as answered. Because of the reputation system it is likely the community will see and answer your question there. This also helps us use the GitHub bug tracker for bugs only. Will close this as this is really a question that should be asked on SO.

[austinksmith]

I think you've misunderstood the question a bit, asyncstorage doesn't function when debugging in chrome and using the emulator. This to me is a major bug as it prevents me from debugging my application.

[DanielMSchmidt]

Sorry for that 😞
@facebook-github-bot reopen

[austinksmith]

It seems to be intermittent when it works, when running on an actual device everything appears to function fine. My use case is basically, I have a splash/login screen and when someone logs in I'm saving a token using asyncstorage, in my homeview I fetch that token from asyncstorage and render a list of events. The problem is when debugging about 70% of the time the homescreen will simply hang, my breakpoints never get hit and the application does not freeze I can still reload the js and enable the perf monitor but it appears my token is never getting fetched from storage which is required for me to authenticate with my api endpoint and render my events so i'm met with my homepage without any events.

I'm emulating a Nexus 5 running android 4.4.4 API 19
Running chrome Version 50.0.2661.102 (64-bit)
Using a MBP Retina running El Capitan 10.11.4
With the following extensions https://www.dropbox.com/s/tdd7zwwnhswul7i/Screenshot%202016-05-20%2016.13.32.png?dl=0

[limemloh]

I have the same issue.
@DanielMSchmidt It seems like the github-bot failed in reopening the issue.

[jgkim]

I have the same issue. When DEBUG JS Remotely is on, accessing AsyncStorage via redux-persist just hang. It works well on iOS.

[DanielMSchmidt]

@facebook-github-bot reopen

[ghost]

Okay, reopening this issue.

[thorstenweber83]

i'm having the same problem running rn-0.31 on the android emulator (Android 6.01) and on a nexus 4 device.
computer is a thinkpad x220 running ubuntu 16.04
chrome version 52.0.2743.82

UPDATE:
it seems weird, but implementing the 'Delay Render Until Rehydration Complete' recipe from the redux-persist repo (https://github.com/rt2zz/redux-persist/blob/master/docs/recipes.md) solved the issue for me...

[jgkim]

@thorstenweber83 I don't know why, but I also confirmed that the Delay Render Until Rehydration Complete solved the issue. @rt2zz Any thoughts?

[benhughes]

I'm getting the same issue in chrome too. Nexus 5 with remote debugging through chrome.
React native version 31.0

After throwing in a few console logs, it seems the callback registered when calling RCTAsyncStorage.multiGet in Libraries/Storage/AsyncStorage.js never gets called. Everything works fine on the device though so it seems to be an issue with the debugger.

[BlooJeans]

Same issue. Sometimes the debugger works fine, sometimes AsyncStorage is (really) slow (3-9 seconds, and I've even seen it take 9 minutes for AsyncStorage.multiGet to return, and sometimes it appears to hang indefinitely (15+ minutes). Turning off Debug JS Remotely seems to solve the issue immediately. Interestingly, I haven't seen the issue occur during the first reload when you turn the debugger on.

I'm running:
(actual device) Nexus 5x on 7.1.1
Chrome 54.0.2840.71
React Native 0.35.0

Edit: I was also already using the 'Delay Render Until Rehydration Complete' recipe, so that seems to have had no effect for me

[bartolkaruza]

This could be the same issue that we are facing here #12830 (no solutions).

[hramos]

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

[Ble3k]

Same issue.

I think this problem should be payed attention.

[austinksmith]

There seems to be a trend of closing out issues when they're only inactive due to users waiting for response from maintainers...not a great practice. Here we are almost 2 years later and this still hasn't been addressed.

[hramos]

The two month inactivity period before closing can be bumped up now that we have a smaller number of open issues, but I'd still recommend submitting a pull request as a more appropriate long term fix. We lean heavily on the community providing fixes for issues they run into. Please tag this issue if a PR is submitted and we can re-open it.

[GmeduoyeClaymore]

@hramos if you don't have anyone to look at the issue how about you write that on the issue and then perhaps someone can pick it up and submit the PR. I don't see what the practice of closing issues that you have not even attempted to reproduce really achieves apart from artificially reducing your list of outstanding issues. I've seen this happen a lot on the react-native project and it's pretty depressing to see a project being run like this.

[cihadturhan]

Maybe related to #14101

[jamsch]

It's really quite a pain trying to debug an Android app. The only time AsyncStorage seems to retrieve the items while in debugging mode is when the app first opens. So a lot of the time when you make changes you'd have to close the app & reopen it.

[Shu-Ji]

the same issue as @jamsch said. I must close and then reopen the app everytime.

[cihadturhan]

I have a theory for a reproduce the issue but couldn't fully test it.
I realized for a couple of times that I reload the app (menu button -> reload) while AsyncStorage.getItem is in progress, it stops working thereafter.

Anyone can confirm?

[austinksmith]

@hramos it is clear this issue is impacting development, please reopen

[lucianomlima]

Have same issue when try to access data stored in AS. Only in Android with debug JS mode on.
Using RN 0.50.4 without redux and redux-persist.

[hramos]

This issue is not getting re-opened. Please go ahead and open a new issue that follows the template, as advised last July.

[austinksmith]

@hramos this issue was open for the last 2 years, additionally the text says

If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.

The caveat is If so is there any information missing from the bug report and the caveat does not apply, there is no information missing from the bug report.

2 years man, get it together guys.

[hramos]

Thanks for your cooperation.

[austinksmith]

@hramos I think we've all been really patient regarding this issue, I am no longer working on react native projects at the moment but these issues that impact the speed of development are reasons why I haven't taken up react native more in my own projects. While my open source project is much less lines of code I am also only one man and I am able to close out all issue tickets with an average time of 2 months at most to get them fixed, Facebook has a market cap of 531.59 billion dollars can we not expect big issues like this to at least be paid attention to in 2 years without being closed out and told dubious reasons why we must now create a new ticket. It's disappointing to see a project being run this way especially one run by a company with so many resources, is it too much to ask that the build tools for the project work as advertised?

[bartolkaruza]

@austinksmith market cap does not give you any silver bullets to solve complex technical issues across many layers of libraries/platforms outside of your control. With all due respect, React Native is tackling the cross-platform challenge better than any other project I've ever tried. Maybe use your energy to dive into the code and look for a solution to the problem yourself? It is all open source for a reason. Anyway @hramos , https://github.com/facebook/react-native/issues/12830 is a duplicate of this issue and it is currently open. Perhaps we can label this one as a duplicate so all the attention can be focused on that one issue. There is no solution there yet either, unfortunately.

[austinksmith]

Wouldn't that ticket actually be the duplicate considering its 12 months
old and this one is 24?

Like I said, I'm no longer using react native for any projects but I am not
obligated to fix the debugging and emulators here. If 2 years is now the
new standard for fixes then I will be sure to avoid rn moving forward.
Market cap shows facebook has capital, to pretend they don't or they can't
afford to invest more resources into their software offerings is a slap in
the face to people who work hard to make sure their own software is as bug
free as possible with significantly less resources at their disposal.

A 500+ million dollar corporation should probably be able to fix an issue
like this within 2 years right?

If not then open source as a whole is a doomed proposition, I also think
it's fair to expect issues not to be closed before they are addressed
either. Its not anyone's fault who had been impacted by the issue (myself
included) that this has happened, it was reported 2 years ago and
maintainers have attempted to close the ticket multiple times without
investigating.

A duplicate was created a year after this one, meaning the duplicate
should have been closed and not the original.

These are my opinions as someone who needs to make technical decisions on
what frameworks to use for upcoming projects, I like what react native is
trying to solve but it makes it difficult to use it when I can't get issue
tickets to even stay open long enough for someone to actually label it as
needing attention or someone to investigate within several years.

On Feb 28, 2018 4:28 AM, "Bartol Karuza" [e-mail] wrote:

@austinksmith https://github.com/austinksmith market cap does not give
you any silver bullets to solve complex technical issues across many layers
of libraries/platforms outside of your control. With all due respect, React
Native is tackling the cross-platform challenge better than any other
project I've ever tried. Maybe use your energy to dive into the code and
look for a solution to the problem yourself? It is all open source for a
reason. Anyway @hramos https://github.com/hramos , #12830
https://github.com/facebook/react-native/issues/12830 is a duplicate of
this issue and it is currently open. Perhaps we can label this one as a
duplicate so all the attention can be focused on that one issue. There is
no solution there yet either, unfortunately.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/7605#issuecomment-369175550,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACH-I7s5QOp2o9mf1a3zIMwtC9dfhUb3ks5tZRwtgaJpZM4IguFa
.

[bartolkaruza]

I was just suggesting the duplicate approach out of practical considerations. Would it make you feel better if that one was closed and marked as duplicate and this one re-opened? Either way, I think it's easier if we have one issue open for it until we can distinguish if this is all caused by the same thing or if we are catching multiple different issues with similar effects. As I said in the other ticket, this is not happening for me anymore (for a long time) and I suspect only a subset of the user base is affected. To be able to find out what subset with which characteristics, we need more information about the causes. The other ticket seems to have more relevant information at this time.

I can't personally look for a solution anymore as I'm not able to reproduce this problem. Without a minimal project showing the issue with exact specs that makes the issue easily reproducible, finding a fix would seem an impossible task for anyone, even Facebook. This is probably why there is some reluctance to keep the issue open. (I'm not connected to Facebook in any way and just an RN user most of the time.)

[austinksmith]

I don't think we should call an original ticket a duplicate and close it out giving the impression that this issue is a year old and not two years old as this ticket shows. It's definitely not in anyone's best interest to arbitrarily close out old tickets, I created this ticket because it impacted my ability to complete a project on time for a company I worked at. Eventually I trialed and errored my way around the problem but this is bad practice on facebook's part and it seems like an attempt to hide the impact of various issues that have existed for a long long time.

If I had been asked to provide a example app I would have done so 2 years ago but this wouldn't have changed much I don't think given this is a trend across 3 out of the 4 tickets i created back then, please don't defend bad practices for issue ticket management on software projects because it sets a bad trend that will be followed by others because of the "If it's good enough for facebook, its good enough for me/us" group think mentality.

I think it's only fair that if these issues exist and they are not going to be resolved that the original ticket conveying the issue stays open if only for the purpose of knowing which issues to prioritize over others based on how long they've existed, closing out an older ticket and calling it a duplicate when it has existed for 12 months longer than the one referenced is an extremely bizarre practice and only seems to serve the purpose of arbitrarily reducing the issue resolution time metric.

[mycoberago]

AsyncStorage works fine using the simulator (when not debugging in chrome), but when using an actual device, it doesn't work. I'm not sure if I've taken all measures, but I just wanted to add to this.

Thanks.

UPDATE
I'm using CRNA with Expo and running the program through the Expo XDE and NOT the terminal allows for AsyncStorage to work consistently--both in the simulator and physical device. I'm not sure how helpful this is but for what it's worth, using RN with Expo through CRNA has been a lot easier for someone like me who's new to mobile app development (first timer) and come from the "front-end" world. So, despite all the hiccups and some limitations, I'm grateful because the app I'm building and will be publishing would be non-existent. 🙏🏽

[OoDeLally]

I switched to Expo XDE, and now using Expo.SecureStore.setItemAsync and it seems to work fine for now.

[sinxwal]

@cihadturhan I think you are right.
I can reproduce this error just by refreshing several times an app (cmd+r).
After that AsyncStorage.getItem does not resolve any value.

[kamenminkovcom]

Guys, did you find a solution for that, switching to Expo Storage is not an option. This issue should be prioritize, I mean it is really hard to understand what happens in the app without debugging, it like shooting in the dark. This makes AsyncStorage completely useless for Android.

[markainick]

I'm facing the same issue.

maxOS Sierra 10.12.6
Chrome 66.0.3359.139
react-native: 0.55.3

And I'm using AVD Nexus 4 API 23.
For me AsyncStorage works as soon as i launch react-native run-android, but it randomly stops working after x reloads, and I have to re-launch run-android. The thing is driving me mad, as I even put a log in my console that tells me if the AsyncStorage is working or not.

[cinder92]

same issue here ....

[coman3]

Im 100% not sure where you guys are having problems with this, i have been using debug mode AsyncStorage on android simulators & devices without any problems. Maybe you are more so having problems with setTimeout, as in debug mode it can be a little glitchy and not call within the time frame expected. (especially if the time on the device and computer are different)

[zero-t4]

getting the same issue... You had 2 years to fix such a bug (not impressed)

[lukszymanski]

same here, issue still there

[kamenminkovcom]

I started working with this standalone debugger: https://github.com/jhen0409/react-native-debugger
I am not sure if it solved the problem, but for now it is working fine.