sheac

Context

We want to use Document checksums on clients to avoid re-fetching binary data we already have.

Checksums are sometimes expected to be NULL

Documents can be uploaded in bits. When they're not finished yet, they have a field pending that's set to true. During this time, the checksum is NULL.

sheac

The problem we encountered earlier was that thrift-api used its own default limit of 50. This would happen if an options map was present, but no limit was entered.

This is now fixed.

Here's the request:

curl -X POST \
 https://api.pow.sera-dev.co/api/messages \

sheac

Jira Tickets

• https://parsable.atlassian.net/browse/PA-14359

• https://parsable.atlassian.net/browse/PA-14361

1. Create a large job by copying adding this template to it about 10 times.

2. Find the job's id

sheac

Question

We are dropping events <1MB. Investigate frequency and identify any possible patterns to determine cause.

Jira Task: https://parsable.atlassian.net/browse/PA-13238

---

Results

sheac

Known Causes

1. Duplicate steps/fields within a single job

   • haven't confirmed any problems resulting from field-sharing yet
   • results from adding the same template multiple times
   • same DB row, but different jobBaseStepIds

2. Shared steps/fields between clone/duplicate jobs and their originals/sources

   • haven't confirmed any problems resulting from field-sharing yet

• results from JobController#CreateFromOffline

sheac

Hey @here

So I've taken on board some useful guidance by @rory and @eric concerning the "right" way to generate a context.Context instance for use by Mothership guts.

I'm given to believe that:

• if we want to trace a DB query, it needs a Context
• if we want the DB query to succeed, that Context has to have been generated in the right way:

handler.Transact(func(ctx context.Context) {...})

sheac

#!/usr/bin/env python

"""
This script monitors Github repos for an organization ("company") and squash-merges pull
requests if someone has commented with the ":shipit:" emoji.

Why would you want to squash pull requests? It makes it very easy to get a high-level overview
of your master/deploy/release branch without getting bogged down in miniature type commits. Also
, on the off chance you need to, rolling back whole features is dead simple. Finally, you can
still retain proper git history if you keep the feature branch that the PR came in on.

sheac

def scale_down(iw, ih, dw, dh)

  # 1. determining which dimension is the one that needs to be
  # scaled the most
  limiting_dim = (iw / ih) > (dw / dh) ? "width" : "height"
  
  # 2. then figure out how much that scaling actually is
  if limiting dim == "width"
    scale_by = dw / iw
  else