-
Notifications
You must be signed in to change notification settings - Fork 0
Squashed Bugs
Alejandro Carrizosa Grant edited this page Jan 18, 2022
·
1 revision
- Data was shared between "MySongs" and "Home". The content of the page would be fine to begin with but would combine with the other page's content as soon as one navigated to the other page. This meant that all of one's created songs would show up, iframes and all, on the home page. Expectedly, this caused tremendous render issues and detracted from the site's overall quality.
- I decided to reorder several sections of my program. I started with my routes, assimilating the mySongs file into Songs. Next, I entered the store and, after experimentation, decided to create another action creator for mySongs after discovering that the states were being combined in my store and thus yielding amalgamated results in either component. After this, I altered the components' useSelectors to reflect the changes in the store.
- I ran into the unique key error on one of my react components, but it didn’t behave normally. I tried several different ways to eliminate it until finally doing this:
<div key={song?.id + 0}>. Any ideas why<div key={song?.id}>wouldn’t work? - Initially, I though it had to do with some other key nested inside the component but there are no other keys present. I wanted to make sure it wasn’t about being a different value than the id so I added 0 instead of some other arbitrary number and like I expected it still worked. But, as soon as I remove the operation or add something like NaN (to check if it’s even hitting there), an error is thrown.
- The
+ 0is behaving like the unary plus. There is typecasting going on the scenes which in my case was favorable but unexpected.
- YouTube creators have the ability to block the ability to embed their links. I ran into this issue after I deployed on Heroku. Every one of the carefully parsed and reconstructed iframes had been blocked.
- So, I used the cover art as the thumbnail, modified my parsing, and converted every one of the iframes into images wrapped in links or which called a handler (for local redirects).
- The spirit of the site was preserved alongside the structure of a significant portion of the codebase. Intriguingly, this all resulted in a net gain for performance which can be attributed to the fact that iframes no longer had to be rendered. Furthermore, the crispness of the cover art I scraped and used to replace the iframe thumbnails resulted in an aesthtic boost to the site. This both speaks to the importance of regularly testing one's deployed site and acts as a testament to how desirable outcomes can be gleaned from undesirable occurrences if one maintains a patient and determined mindset.
- On my deployed site, the following error prevented any of my images from being rendered:
images.genius.com/9dc66306cd3f6d048434600ad9fea747.1000x1000x1.jpg:1 GET https://images.genius.com/9dc66306cd3f6d048434600ad9fea747.1000x1000x1.jpg net::ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep 200 - Chrome DevTools stated the following:
Because your site has the Cross-Origin Embedder Policy (COEP) enabled, each resource must specify a suitable Cross-Origin Resource Policy (CORP). This behavior prevents a document from loading cross- origin resources which don’t explicitly grant permission to be loaded. ...
- In each image, I placed the following:
crossOrigin={process.env.NODE_ENV === 'production' ? 'anonymous' : false}. -
process.env.NODE_ENV === 'production' ?assures thatcrossOrigin='anonymous'is utilized only for deployed environments (otherwise, the issue reverses and the local environment doesn't render images while the deployed one does).
- The OS Monterrey on Mac appropriated port 5000 for use by AirPlay, (checking or unchecking the AirPlay Reciever in settings controls this function).
- I thought that changing my /backend/config/index.js, /backend/env, and /frontend/package.json files alone would rectify this; however, this resulted in an enigmatic error—all requests were returning 403s:
Proxy error: Could not proxy request /erudite/session from localhost:3000 to http://localhost:5000. See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED). - Turning off AirPlay in my settings and setting my routes back to 5000 allowed the requests to be properly processed again. This was not meant to be a longterm fix, merely to narrow down what the radix of the bug could be. The error is pointed to localhost:5000 when it should be recognizing localhost:5500 as the current proxy. I restarted the servers and the 403s turned into 404s, no longer forbidden but the resources were still unavailable.
- I felt that something must be lurking in the background that relied on the backend port, some process that was not included in the three aforementioned files within which I indicated the new port or which was not registering the changes (using old data much like the proxy issue previously encountered). That's all that seemed to explain how this could work on the deployed site (which runs its own servers) and locally with AirPlay turned off (freeing up the original port which could be in use in more than the three locations I modified).
- I removed the port variable from my .env to eliminate redundancy, thereby preventing future conflict with the host's ports for the deployed site. This is because the line where it is referenced in /config/index.js is meant to allow the host Heroku to interject the port it sees fit:
port: process.env.PORT || 5500and to use the specified port for all other cases. - I exited out of the VSCode window containing the project and restarted the server multiple times to no avail. I noticed a favicon from another project (not currently running on that port) was persisting in the tab of port 3000 even upon hard refresh and that made me recontemplate my previous postulation that stale data usage by one of the processes could be the matrix of this error. I resolved to shut down VSCode completely, restart my computer, and rerun my front and backend servers. This proved successful.
- I removed the port variable from my .env to eliminate redundancy, thereby preventing future conflict with the host's ports for the deployed site. This is because the line where it is referenced in /config/index.js is meant to allow the host Heroku to interject the port it sees fit:
- An odd behavior with the scraper I discovered was that the terminal seemed to have memory of my last search.
- I had to restart my server, kill my terminal, take out the comments, and clear the file, to prevent it fetching from code that had already been commented out throughout the entire document. There was no other clear explanation other than the terminal retaining previous calls.
- React was rasing an error on two children bearing the same key, pertaining to the MySongsPage component. I realized that setting the key to the YouTube iFrame id wasn't as unique as I thought, It turns out that there were several hash collisions.
- I changed it from using the second capture group in my iFrame regex:
{song.media.replace(iframeRegex, '$2')}to accessing the song's id from the database:song.id.
Row Size Exceeded Problem
index row size 3624 exceeds btree version 4 maximum 2704 for index "Songs_body_key"
- There was too much indexing required from database to determine if each line was unique. I decided to add strings to a Set object beforehand and take the constraint out of database so to lessen the strain.
Sequelize Can't Resolve Error
Unable to resolve sequelize package in /app
-
I was using the incorrect set of commands:
<!-- I needed to use: --> heroku run npm run sequelize db:seed:undo:all heroku run npm run sequelize db:migrate:undo:all heroku run npm run sequelize db:migrate heroku run npm run sequelize db:seed:all <!-- Instead of: --> heroku run npx sequelize-cli db:seed:undo:all heroku run npx sequelize-cli db:migrate:undo:all heroku run npx sequelize-cli db:migrate heroku run npx sequelize-cli db:seed:all