Metadata's buildEpoch parsed as a string instead of integer.

[acelaya]

Hello.

I'm using this library in a project where I have a small mechanism to programatically update the GeoLite2 database file from time to time.

The logic is based on the database file build epoch, which I'm getting from the MaxMind\Db\Reader\Metadata object.

This object states that the buildEpoch property is an integer:

However, I have a user that has reported an error because that value is coming as a string, and is making a later statement fail because there's a type hint to int somewhere else.

I haven't been able to reproduce it myself, but I have asked him to var_dump the metadata object, and it has been parsed as a string for him.

object(MaxMind\Db\Reader\Metadata)#161 (11) {
  ["binaryFormatMajorVersion"]=>
  int(2)
  ["binaryFormatMinorVersion"]=>
  int(0)
  ["buildEpoch"]=>
  string(10) "1611667589"
  ["databaseType"]=>
  string(13) "GeoLite2-City"
  ["description"]=>
  array(1) {
    ["en"]=>
    string(22) "GeoLite2 City database"
  }
  ["ipVersion"]=>
  int(6)
  ["languages"]=>
  array(8) {
    [0]=>
    string(2) "de"
    [1]=>
    string(2) "en"
    [2]=>
    string(2) "es"
    [3]=>
    string(2) "fr"
    [4]=>
    string(2) "ja"
    [5]=>
    string(5) "pt-BR"
    [6]=>
    string(2) "ru"
    [7]=>
    string(5) "zh-CN"
  }
  ["nodeByteSize"]=>
  int(7)
  ["nodeCount"]=>
  int(4150659)
  ["recordSize"]=>
  int(28)
  ["searchTreeSize"]=>
  int(29054613)
}

I asked him to share his database file, and for me it's parsed as an integer, so I'm not sure what could be the difference.

Is there a known combination of circumstances in which this could end up happening?

I have considered just casting the value to integer always, but I'm afraid that could mask other errors that would be harder to identify later on.

[oschwald]

If I had to guess, I would speculate that he is on a 32 bit system where gmp/bcmath is used for generating 64-bit integers. Could you confirm his platform and whether he is using the pure PHP implementation of this module or the maxminddb extension?

[cnxsoft]

Yes, I am on Ubuntu 18.04 32-bit. I'm not quite sure how to check whether it's using the PHP implementation or the maxminddb extension.

[oschwald]

@cnxsoft, would you be willing to share the output of php -i? Also, what version of this module are you using?

[cnxsoft]

php -i output:
https://pastebin.cnx-software.com/?d3aa526e386ea9c7#9p9MwD3sXDze4fk8hMR6t6bF3RGR6e4z6NVKbqGgrCFJ

But shlink website is configured to use php7.4, so here's php7.4 -i output as well:
https://pastebin.cnx-software.com/?32c332dbb032f963#oBWksYeKY5Erg869Ec4tL3KU691PMY2GjZQn6mkqTio

I'm using a shlink 2.5.2 program using maxmind-db-reader. I'll let @acelaya answer about the exact version of the module used in the program.

[acelaya]

It's v1.9.0

[oschwald]

It appears that you don't have the maxminddb extension or GMP installed. The string value is likely coming from BCMath.

As an immediate fix, I think using the maxminddb extension, which can be installed from PECL would resolve the issue in this particular case.

As for the larger issue, I think this module could cast the value if it is less than PHP_INT_MAX, which would solve the build epoch issue for the foreseeable future. We might want to think about some of our documentation around other ints for 32 bit PHP versions.

[acelaya]

For now, I have worked around this in Shlink by doing a cast to int, with some extra checks to avoid silent errors.