Recent Posts

Elixir Wallaby uncaught JavaScript error

If you see this error, you may likely have a JS error that has crept in to your JS build you did not realize:

** (Wallaby.JSError) There was an uncaught JavaScript error:

My full error ended up resolving to an app.js file, which took me a second to realize had some new code on a pre-login page. This ended up explaining why the login tests were failing when the login form was loaded (who would have thought?).

The generic nature of the js file (app.js) made it so I did not initially recognize some local code was calling a function on a non-existent element from a DOM query, which was resolving to undefined (so the classList property being referenced was failing).

 ** (Wallaby.JSError) There was an uncaught JavaScript error:
     
webpack:///./js/app.js? 115:22 Uncaught TypeError: Cannot read property 'classList' of null

I have found that issues like this will likely have more to do with local code. The default logger settings are somewhat helpful, and the stack trace eventually resolved to (wallaby 0.28.0) lib/wallaby/chrome/logger.ex:8: Wallaby.Chrome.Logger.parse_log/1.

It took me a minute to realize the app.js here was our local webpack build, not some internal Wallaby build of some sort. If Wallaby is truly the issue, you can try and update dependencies, and I would note you would something more similar to a Chromedriver session id error, as with https://n8williams.com/devblog/general_dev/elixir-wallaby-and-chromedriver-issue-runtimeerror-invalid-session-id.

To this point I have been very pleased with Wallaby, I cannot recommend it enough for acceptance testing, etc!

local -A invalid option, the outdated bash A option issue

TL/DR; Make sure your bash or shell program is up to date, with something like brew install bash. Especially if you are on a Mac, and have updated the OS recently.

If you see this error: local: -A: invalid option

There are a number of things that may be triggering this. For me, it was an asdf install of an plugin for a new version of Node.js. Or in a nutshell, an issue trying to update my version of node.

When I did some digging into the line of a node install util, I found there was a bash script that as calling something using an -A option in lib/utils.sh: line 35: local: -A: invalid option.

I was curious why -A would not work, and when I issued the command bash --version, from my shell it was a version from 2007! I can’t believe I have gotten away with using a 2007 shell for so long.

The new Mac OS versions use zsh/the Z shell, and one option is to use this. I did not heed Mac’s warning: The default interactive shell is now zsh … See: https://apple.stackexchange.com/questions/371997/suppressing-the-default-interactive-shell-is-now-zsh-message-in-macos-catalina

As I use a lot of bash aliases, I was a bit wary of switching to the z shell, so I just made sure to install an updated version of bash using homebrew. I plan on looking into the Z shell sometime soon and maybe maybe the switch. It appears there are some niceties to zsh vs bash. There are some great resources on making the switch, my favorite being: https://carlosroso.com/the-right-way-to-migrate-your-bash-profile-to-zsh/

nginx client_body_temp failed 13: Permission denied error

With nginx and homebrew installs, you may see the following error if you have installed nginx with homebrew (or otherwise) and are seeing errors when you try an upload files using wordpress or otherwise:

nginx/client_body_temp/0000000007" failed (13: Permission denied) where the number of the temp directory may be different.

The /usr/local/var/run/nginx folders may have been set with restrictive users or permissions (or depending on your setup something like /opt/homebrew/var/run/nginx). Cd into that folder with cd /usr/local/var/run/nginx and run sudo chown -R <your_admin_user>:admin client_body_temp/ to allow the right processes to be able to upload the files.

Homebrew postgres and psql error: could not connect to server icu4c error

10:36:54.086 [error] Postgrex.Protocol (#PID<0.522.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (127.0.0.1:5432): connection refused - :econnrefused

psql: error: could not connect to server: could not connect to server: No such file or directory<br>Is the server running locally and accepting<br>connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Even if brew services restart postgres is successful, there may be an error occurring, view your log, which for me with homebrew’s install was tail -n 50 /usr/local/var/log/postgres.log. If you see something like the following, you may need to switch a package version back to something older:

dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.64.dylib<br>Referenced from: /usr/local/opt/postgresql/bin/postgres<br>Reason: image not found

For me, after an OS update, the icu4c package had been changed, so I needed to switch it back, using brew switch icu4c 64.2

Elixir Wallaby and Chromedriver issue: (RuntimeError) invalid session id

 1) feature does X (BaseApp.UIWeb.Test.Acceptance.TheTest)
     apps/ui/test/ui_web/acceptance/the_testexs:13
     ** (RuntimeError) invalid session id
     code: |> session_login()
     stacktrace:
       (wallaby) lib/wallaby/httpclient.ex:136: Wallaby.HTTPClient.check_for_response_errors/1
       (wallaby) lib/wallaby/httpclient.ex:56: Wallaby.HTTPClient.make_request/5
       (wallaby) lib/wallaby/webdriver_client.ex:254: Wallaby.WebdriverClient.visit/2
       (wallaby) lib/wallaby/driver/log_checker.ex:6: Wallaby.Driver.LogChecker.check_logs!/2
       (wallaby) lib/wallaby/browser.ex:963: Wallaby.Browser.visit/2
       (ui) test/support/acceptance/rivendell_wallaby_session.ex:73: Rivendell.UIWeb.Test.Support.Acceptance.RivendellWallabySession.session_login/1

The solution for this was to run: brew upgrade chromedriver (this used to be brew cask upgrade chromedriver). You may possibly need to update your chrome browser. The comments on this issue/repo were very helpful: https://github.com/elixir-wallaby/wallaby/issues/468.

Generally, it would seem it is a good idea to keep your chromedriver in sync with your updates to Chrome (run brew upgrade chromedriver when you update Chrome.

More general errors will likely be an issue with your local code as opposed to Wallaby or package dependencies 🙂 See: https://n8williams.com/devblog/general_dev/elixir-wallaby-uncaught-javascript-error

Codeship apt-get update errors and yarn and command returned a non-zero code 100

TL/DR: apt-key adv --refresh-keys --keyserver keyserver.ubuntu.com (use with caution) may go a long ways in getting your build to work.

Some noteworthy things after learning about the interplay between codeship, docker, ubuntu apt-get, and the yarn package. This resolution may help with issues dealing with:

  • Invalid signatures with the yarn ubuntu package.
  • Errors running apt-get update
  • Errors updating the Dockerfile for a CodeShip build
  • Dealing with CodeShip build steps updates and cached steps

For now, I’m noting my crazy sequence of realizations in reverse order

A failed step on the server with CodeShip may not be very enlightening. If you see an apt-get install -y <some-package> returned a non-zero code: 100 error, you may need to run the step locally to see the full error using jet steps.

If you see the above error, it may be due to a command in your steps if the RUN command in the Dockerfile includes apt-get update -y

The apt-get update may be failing because a package includes an invalid key. This may be the yarn package, spitting out GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG XXXXXXXX Yarn Packaging <yarn@dan.cx>. If you add apt-key adv --refresh-keys --keyserver keyserver.ubuntu.com this may resolve that issue. See https://github.com/yarnpkg/yarn/issues/7866

You may see a codeship error like:
2 errors occurred:
* (step: dependencies_X-deps) error loading services during run step: failure to build Image{ name: "static.X", dockerfile: "/<project-path>/docker/app/Dockerfile", cache: true }: The command '/bin/sh -c apt-get update -y   && wget https://dl.google.com/linux/direct/google-chrome-stable_beta_amd64.deb   && apt-get install -y ./google-chrome-stable_beta_amd64.deb   && rm google-chrome-stable_beta_amd64.deb   && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100
…

With codeship steps, if you edit the Dockerfile RUN command, and it is equivalent to a previous version of that RUN command, that command will be cached and may not trigger an error you expect. In this case it was more painful when trying to add a separate and new RUN command with apt-get install -y libxss1 while updating the build to have a chrome install with the libXss dependency included.

The ubuntu stable package may no longer work for you if you are using puppeteer in conjunction with a headless chrome browser to generate screen captures/pdfs on a server. It can be a bit painful to locate a list of package versions for chrome on ubuntu, and sticking with stable and adding a apt-get install -y libxss1 to your RUN command is one way to go. This may stem from seeing something like:
/app/pdf-thing/node_modules/puppeteer/.local-chromium/linux-XXXXX/chrome-linux/chrome: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory

Error on Startup and Boot Failure for MacOS After Converting SSD to APFS. Running bless to place boot files failed.

I wanted to offer some more clarity on converting a hard drive to the AFPS format, for upgrading from Mojave to Catalina, or something similar. I could not upgrade without doing so. I was surprised at how technical the process was, but I think it’s manageable for most people. Though terrifying to have to adjust boot settings (back in my windows days this was a non-recoverable screwup at times). After a successful conversion to AFPS, I could not boot out of recovery mode and would get the “Running bless to place boot files failed” error.

First convert the Hard Drive

  1. Any backing up, I would make sure to do before converting. I put that off, and ended up being fairly nervous when my OS would no longer boot 🙂 Luckily, I ended up back with the same OS with a converted hard drive and proceeded to upgrade.
  2. For me, I had to boot in recovery mode to get the option I needed. Restart your Mac and hold down Cmd+R to boot into recover mode.
  3. Launch the Disk Utility app from the options.
  4. Select your hard drive and then its main volume, then unmount it (I had to do this to get the convert option to be enabled).
  5. Select Edit then Convert to APFS
  6. It should convert after about two minutes and you can reboot.

At this point, I restarted and found my Mac would always boot into recovery mode. When I selected the main hard drive and tried to restart from that, I got an error, indicating “Running bless to place boot files failed.” There were some helpful sites, but the instructions didn’t quite match up for me, and the more technical part of creating a folder with the hard drive’s unique id was not very clear. The following are the steps I took, but see: https://www.tecklyfe.com/boot-failures-after-converting-macos-ssd-to-apfs/ and https://apple.stackexchange.com/questions/308531/could-not-create-a-preboot-volume-for-apfs-install (You may be able to do this in a shorter number of steps than me)

  1. In recovery mode open the terminal from the menu Utilities -> Terminal.
  2. List the hard drive info with diskutil apfs list
  3. If you’re like me you already have a preboot volume. But apparently you may need to create one with diskutil apfs addVolume disk"Disk Number here" apfs Preboot -role B
  4. The steps in the articles I was seeing got less clear to me here. Props to the existing info, but I wanted to add my two cents. At this point I needed to copy existing preboot files into another preboot folder. Before I could use a copy command, I had to create a new preboot folder with the UUID of the hard drive volume disk2s1 (or whatever your main apfs partition is listed as in the diskutil afps list command. UPDATE: The UUID to use should be the that of the primary partition (and not the pre-boot partition) – thanks to opherko. The command I needed was: mkdir -p /Volumes/Preboot/<The UUID, a long alphanumeric id>/System/Library/CoreServices
  5. At that point I could do cp -RP /Volumes/<Your hard drive name here>/System/Library/CoreServices /Volumes/Preboot/<The UUID>/System/Library/CoreServices. It would seem to me you are copying your old, functioning boot files into a new boot folder for your converted hard drive. Perhaps temporarily until another process adjusts things. Make sure, as noted above, that the UUID is the primary partition’s UUID.
  6. Now you can run the update commands for the preboot. Replace disk2s1 with your disk: diskutil apfs updatepreboot disk2s1
  7. Run the bless utility: bless --folder /Volumes/<Your hard drive name here>/System/Library/CoreServices --bootefi --verbose
  8. You may need to use the Startup program to assign the boot partition when exiting the utilities.
  9. At this point I was very relieved that upon trying to reboot, you should no longer get the error “Running bless to place boot files failed.” and the OS should start. For me, I was back in Mojave, with all my same files on a hard drive that was now formatted for AFPS, where I could proceed to install Catalina. Hopefully this informs a successful end result for someone else out there.

Getting the current date for a timezone with Elixir

Issue: Getting the (current or otherwise) date for a specific timezone can be involve some trickiness.

Example: I want to show the current date in New York, even though I reside in Austin, TX. If it is 12/11/2020 11:39 PM CT:

  • The display for NY data should show 12/12/2020
  • A display for Austin, TX would show 12/11/20202

One solution:

NOTE: When dealing with DateTimes to save to a database, leaving the microseconds on can cause issues. I’m surprised the DateTime result doesn’t default to the more compatible format (TBD on whether from Elixir or Timex). See https://github.com/riverrun/phauxth-example/issues/10