astorm
Repos
114
Followers
708

A collection of command line scripts for Magento 2 code generation, and a PHP module system for organizing command line scripts.

524
99

A small shell script to automatically package tar archives into Magento's Connect 2.0 format.

81
24

The fastest way to browse your Magento admin interface.

25
11

An example travis configuration for getting a Magento 2 enviornment up and running

43
12

Events

pull request opened
feat: container-info import and ECS Container Information

Draft PR for pulling container-info into this repo and discussion over how to reconcile container-info with our own specs.

Our spec states we should extract the container info in an ECS environment with ^[[:xdigit:]]{32}-[[:digit:]]{10}$. However, container-info references an ecs metadata file located at process.env.ECS_CONTAINER_METADATA_FILE which contains container metadata that includes the container ID. The container-info fixtures suggest the ^[[:xdigit:]]{32}-[[:digit:]]{10}$ regular expression is incorrect.

To Do:

  • Decide if we should honor the spec as is, or redefine the spec to use ECS_CONTAINER_METADATA_FILE (confirming that ECS_CONTAINER_METADATA_FILE and the spec actually disagree
  • Determine if our cgroup_parsing specs are incorrect about the testUbuntuCGroup test
Created at 2 days ago
astorm create branch astorm/container-info
Created at 2 days ago
Incorporate cgroup_parsing.json into Container Info Testing

There's now a cross agent spec for cgroup parsing, added here.

We should consider using this file in our test suite. Problems to solve with that

  1. How to sync spec to the http client repository
  2. How to deal with discrepancies between our established container parsing and the rules in this cross agent spec (the testUbuntuCGroup fixture yields different results
Created at 2 days ago
issue comment
Reporter for OTel Metrics

Thanks for the insight both @axw, @jackshirazi.

Follow up question for anyone -- OTel has six metric types (Counter, Asynchronous Counter, Histogram, Asynchronous Gauge, UpDownCounter, Asynchronous UpDownCounter)

Has anyone done the work yet to map how these data types would be represented in the intake/v2 protocol?

Created at 3 days ago
issue comment
Reporter for OTel Metrics

@AlexanderWert (or anyone) naive question -- is the intention here that a user will add the OpenTelemetry metrics API/SDK to their project, use that to generate metrics, and then

  • The Metrics Reporter will report those metrics into the configured APM Server using APM Server's OTLP endpoint?

  • The Metrics Reporter will report those metrics into APM Server using the traditional metricset endpoint?

Created at 4 days ago

feat: legacy mode uses new connection options

Created at 5 days ago

feat: debugging jenkins

Created at 5 days ago

feat: final tav addition

Created at 6 days ago

feat: more version shenangins

Created at 6 days ago

fix: more version shenanagins

Created at 6 days ago

feat: usual node 8 exceptions

Created at 6 days ago

feat: ndoe 4.0.6

Created at 6 days ago

feat: node 4.06

Created at 6 days ago

feat: host/port options

feat: const and let not var for new tests

Created at 6 days ago

feat: inevitable docs PR

Created at 6 days ago

test: lock to mongo:5 container, recently released mongo:6 breaks our healthcheck (#2936)

With MongoDB 6 containers (released in the last week), the mongo binary is gone, replaced by mongosh. See https://github.com/docker-library/mongo/issues/558

Our tests were using mongo:latest. For now let's lock to mongo:5 and then have a separate issue for updating container versions for testing.

fix: graphql instrumentation for versions <=0.9 were broken (#2927)

The changes in #2761 to support graphql@16 accidentally broken instrumentation for really old graphql (versions before 0.10.0). This wasn't noticed because the .tav.yml block for older graphql versions didn't have name: graphql, so it was never run in CI.

chore: add a dev utility to list issues with instrumention module version ranges (#2924)

'dev-utils/bitrot.js' is a small CLI that will compare the entries in ".tav.yml" and "supported-technologies.asciidoc" for inconsistencies and for whether our supported instrumentation version ranges are behind current releases.

Helpfully, this parsing also noticed a couple errors in our .tav.yml (missing "name: ..." params) that were resulting in use not testing some older module versions.

chore(deps-dev): bump pg from 8.7.3 to 8.8.0 (#2934)

chore(deps-dev): bump fastify from 4.4.0 to 4.6.0 (#2932)

chore(deps-dev): bump @types/node from 18.7.16 to 18.7.18 (#2931)

ci: remove Integration Tests stage (#2940)

Refs: https://github.com/elastic/apm-integration-testing/issues/1523

test: reduce TAV tested versions of aws-sdk (#2942)

This reduces from 97 versions tested down to 7.

Merge branch 'main' into astorm/redis-4

Created at 1 week ago

feat: redis version stuff

Created at 1 week ago

feat: restore working code

feat: final todos

feat: lint

Created at 1 week ago
pull request opened
draft: redis 4 instrumentation

Checklist

  • [x] Implement code
  • [ ] Add tests
  • [ ] Update TypeScript typings
  • [ ] Update documentation
  • [ ] Add CHANGELOG.asciidoc entry
  • [ ] Commit message follows commit guidelines
Created at 1 week ago
Group Instrumentations by Logical Name

As the modules we instrument become more complex in their construction (more class based modules, more typescript compiled modules), we've found that there's often a need to do deep instrumentation of a specific file in a module. i.e. it's no longer sufficient to instrument redis, we need to instrument @redis/client/dist/lib/client.

This presents some potential confusion around the disableInstrumentations key -- in order to disable an instrumentation multiple keys may need to be added to this data structure.

We should consider changes that would end-users to think of our instrumentations as logic entities rather than individual module files. To quote from a separate discussion

Users might prefer to have the disableInstrumentations key for this be "redis" rather than "@redis/client/...".

This would need some structural changes in instr/index.js for this (a richer MODULES).

Created at 1 week ago
opened issue
New SocketClosedUnexpectedlyError Error When Upgrading from 3 to 4 via Legacy Mode

Hey all -- I'm not sure if this is a bug or just some "how do I redis" questions -- if there's a better place for this please let me know.

We have some old redis code that uses the callback APIs that we want to keep running by using legacy mode. However, when we run this code that's shaped a bit like this simplified example

var redis = require('redis')
var client = redis.createClient({
    port: '6379',
    host: process.env.REDIS_HOST,
    legacyMode: true
})

client.on('error', err => console.log('client error', err));
client.on('connect', () => console.log('client is connect'));
client.on('reconnecting', () => console.log('client is reconnecting'));
client.on('ready', () => console.log('client is ready'));

client.connect()
client.flushall(function (err, reply) {
    client.set('key', 'value', function (err, replies) {
      console.log("key set done")
      client.quit()
    })
})
console.log("main done")

We end up with a new SocketClosedUnexpectedlyError error, and then the program hangs without exiting

% node working.js
main done
client is connect
client is ready
key set done
client error SocketClosedUnexpectedlyError: Socket closed unexpectedly
    at Socket.<anonymous> (/Users/astorm/Documents/redis4/node_modules/@redis/client/dist/lib/client/socket.js:182:118)
    at Object.onceWrapper (events.js:422:26)
    at Socket.emit (events.js:315:20)
    at TCP.<anonymous> (net.js:673:12)
client is reconnecting
client is connect
client is ready
// program hangs
 

With redis@3.1.2 this program runs (minus the client.connect()) without issue and exits with a status code of zero (the real program we have is more complicated, this is the simplified example of the behavior we're seeing)

  1. Is there any known issue what would lead to this sort of calling pattern producing a SocketClosedUnexpectedlyError error?

  2. Do you have any theories on why the program just hangs at the end? (I'd presume a client that's waiting to disconnect)

  3. Is there a way to tell the client is should not automatically reconnect when this sort of error happens?

Environment:

  • Node.js Version: v14.16.1 and v18.4.0 <!-- e.g. "node --version" -->
  • Redis Server Version: 7.0.5 (docker redis:latest)
  • Node Redis Version: 4.3.1
  • Platform: Docker Desktop on MacOS 10.15.7
Created at 1 week ago

feat: switch to disconnect

Created at 1 week ago