Health endpoint doesn't show a version when built from master

Moved from GitHub dgraph/5721

Posted by MichelDiz:

Health endpoint doesn’t show a version (at 8080/health) when built from master - This causes a block on Ratel UI. Also, any Dgraph version will get blocked by this. Not sure if this needs to be fixed on Dgraph itself or Ratel. Pinging @paulftw.

2 potential bugs (both true, not sure if both can be solved at Dgraph side)
1 - When using master, ratel thinks I’m using an old version.
2 - Got “Unsupported Content-Type”.

What version of Dgraph are you using?


Have you tried reproducing the issue with the latest release?


What is the hardware spec (RAM, OS)?

Darwin 32GB

Steps to reproduce the issue (command/config used to run Dgraph).

  1. Build Dgraph from master or any PR.
  2. Start Dgraph’s cluster built from master and run Ratel.
  3. Connect Ratel to http://localhost:8080

Captura de Tela 2020-06-24 às 11 58 24

  1. Now open the console (F12)

You might see in some moment an error like:

Login Failed http://localhost:8080 Error: Pre v1.1 clients do not support Login methods

Also several errors like:

serverAclState error t: Unsupported Content-Type. Supported content types are application/json, application/graphql+-

This is a normal health endpoint

Captura de Tela 2020-06-24 às 11 45 27

And this is the one from master/PR builds.

Expected behaviour and actual result.

That it should work with master builds.

rahulgurnani commented :

Also the dgraph version that is being passed as argument while building go is incorrect. If you execute git describe of master branch, we get v2.0.0-beta1-508-g931b8a81b instead of v20.07.0-beta.Jun22.

rahulgurnani commented :

I can work on this.

dmitryyankowski commented :

I’m on master and also getting the error Pre v1.1 clients do not support Login methods

Any updates on this? Thanks

rahulgurnani commented :

Raised a PR for this.

MichelDiz commented :

@rahulgurnani This fixes the issue with the wrong tag. But the issue with empty values continues. Anyway, I have found that this happens only with go build. And I think the issue is that, we have to discourage users from building it with golang build. They must use make dgraph.

rahulgurnani commented :

Yes they should be using make install. This also happens when running dgraph in debug mode.

MichelDiz commented :

Sure, in VScode debug mode this is a blocker. We can’t use Ratel there. Se we need a “default” value set for cases like that.

There are 2 things:

  1. /health doesn’t show dgraph version when using go build. This is expected. I think developers should be using make install from /dgraph directory. It passes bunch of ldflags.

  2. the /health endpoint shows dgraph version incorrectly on master. This is a bug. I think if the branch is master, we can take dgraph version number to be a large constant, like v99 and also append the commit id to it. This way we would be sure in Sentry that alert was from master with specific commit. Also it would help us avoid any issues that client may face because of a version check because such are usually Version <= x.y type of check (i.e. older than x.y) and a large version number would act like the most recent version.
    Do let me know your thoughts, I will make the change accordingly.

@dmai @Paras

I am on board with the v99-g<commit-id> approach. But it will be good to check what some of the other popular OSS do for their master branch.

Related to health checks, there should be a consideration for orchestrators like Kubernetes:

  • liveness - does service need to be restarted due to failure?
  • readiness - can service accept queries, mutations, etc.

I am not sure if we thought about this, but it would be nice to have direct support. Currently, we are challenges:

  • readiness - how we communicate to service we are ready? We have tried using /state, but restart loops where the pods get killed because other members were not yet available, so the cluster never came back online from a failure.
  • health endpoint w/ long startup times, as badger took like time to come up (minutes), so while this is happening pod would get killed. Currently exploring startupProbe that is commonly used for legacy applications that had long startups as a workaround.

I couldn’t find an OSS which does something like this. Many people update version manually. I have personally used this earlier and it used to work, without developers having to worry about updating version manually with every release.

For comparison, Hashicorp tools do this:

$ terraform version
Terraform v0.12.26

Your version of Terraform is out of date! The latest version
is 0.12.28. You can update by downloading from
$ packer version
Packer v1.3.4
$ vault version
Vault v1.4.2
1 Like

Hi All. I’m just getting familiar with Dgraph. I ran into this issue trying to build Dgraph on a Windows machine where I don’t have admin rights and I can’t run make or Docker, so had to build with go build. Seemed to work fine until I realized this issue with Ratel. Per this comment, I was able to add the -ldflags arguments from the Makefile and get the go build to work (Ratel is now fully enabled). One of the benefits of go is cross-platform capability. Would be good if Dgraph could support the go build directly or offer a CMake option for Windows.

Hello. I am asking this to understand your use case. You are on a restricted Windows laptop without administration rights or ability to grant yourself administrative rights? I was thinking to try this out as through a non-admin user. Could you install software, or you have to use a restricted list that has cmake? Could you use make from MSYS2?

It’s a work laptop with a restricted list that includes CMake. No MSYS2. For security reasons, Docker is not permitted.

Dgraph supports go build. The Makefile is solely a convenience tool used to run go build with the ldflags to set the version info in the built binary. You can build that way or use the release binaries we publish for Windows.

1 Like